| how to determine which TLS ciphersuite was negotiated for a client connection [message #1843188] |
Mon, 19 July 2021 14:38  |
 dev@ datenheim
Messages: 4
Registered: July 2021
Location: Berlin |
Junior Member |
|
|
I have mosquitto 2.0.11 successfully running with Letsencrypt certificates on a host.
TLS 1.2 and higher is enabled, TLS on port 8883 is enforced, no Reverse-Proxy is used, clients connect directly to mosquitto service.
mosquitto.conf:
log_type all
log_timestamp true
log_timestamp_format %Y-%m-%d_%H:%M:%S
connection_messages true
allow_anonymous false
require_certificate false
password_file /etc/mosquitto/passwd
retain_available true
persistence true
persistent_client_expiration 2d
autosave_interval 1800
autosave_on_changes true
max_inflight_messages 20
max_queued_messages 1000
listener 8883
certfile /etc/mosquitto/certs/cert.pem
cafile /etc/mosquitto/certs/chain.pem
keyfile /etc/mosquitto/certs/privkey.pem
dhparamfile /etc/mosquitto/dhparam4096.pem
tls_version tlsv1.2
All that is working fine for all my clients.
But Is there a way to determine which ciphersuite was negotiated/used between mosquitto and the client for it's connection?
Is there a log option to show that?
even log_type all does not do the job here.
[Updated on: Mon, 19 July 2021 14:38] Report message to a moderator |
|
|
|
|
| Re: how to determine which TLS ciphersuite was negotiated for a client connection [message #1844922 is a reply to message #1843199] |
Wed, 29 September 2021 16:40  |
dev@ datenheim
Messages: 4
Registered: July 2021
Location: Berlin |
Junior Member |
|
|
Hi Roger,
thanks for implementing this addition log output :-)
I compiled the "develop"-version and did some tests.
My mqtt exporer connection is successful, the logfile reads:
2021-09-29_17:47:00: New connection from 91.11.83.21:7626 on port 8883.
2021-09-29_17:47:00: New client connected from 91.11.83.21:7626 as mqtt-explorer-stefan (p4, c1, k60, u'logger').
2021-09-29_17:47:00: No will message specified.
2021-09-29_17:47:00: Client mqtt-explorer-stefan negotiated TLSv1.3 cipher TLS_AES_256_GCM_SHA384
Client device SARA-U201:
2021-09-29_17:59:02: New connection from 18.197.48.88:21345 on port 8883.
2021-09-29_17:59:04: New client connected from 18.197.48.88:21345 as uvi_017 (p4, c1, k180, u'logger').
2021-09-29_17:59:04: No will message specified.
2021-09-29_17:59:04: Client uvi_017 negotiated TLSv1.2 cipher AES256-SHA256
2021-09-29_17:59:04: Sending CONNACK to uvi_017 (0, 0)
2021-09-29_17:59:05: Received SUBSCRIBE from uvi_017
2021-09-29_17:59:05: v1/devices/me1/inputmsg/+ (QoS 1)
2021-09-29_17:59:05: uvi_017 1 v1/devices/me1/inputmsg/+
2021-09-29_17:59:05: Sending SUBACK to uvi_017
Client device LISA-U200 V03 said to also support the same TLS versions:
2021-09-29_17:56:29: New connection from 18.197.48.88:3399 on port 8883.
2021-09-29_17:56:29: OpenSSL Error[0]: error:14201044:SSL routines:tls_choose_sigalg:internal error
2021-09-29_17:56:29: Client <unknown> disconnected: Protocol error.
Thus the question remains:
Which ciphers have been negotiated - if any, or has the negotiation failed with "no common cipher found"?
The error message may somehow be related to "signature algorithm".
Maybe I must ask the OpenSSL-folks about it?
Background: I'm working with several kinds of u-blox devices.
All of them are said to support TLS of at least V1.1 but also V1.2.
True for LARA-R211 and SARA-U201, working as expected.
But LISA-U200 does not connect to mosquitto 1.6 and 2.0, while it connects to mosquitto 1.4 - reason unknown.
I have checked all supported cipher suites from the u-blox manual and found out that LISA-U200 supports ALL the same ciphersuites and also TLS_PSK_WITH_AES_256_CBC_SHA which is not supported by the others.
This is really strange!
Regards, Stefan
|
|
|
Powered by
FUDForum. Page generated in 0.03302 seconds
] 
Search
Help
Register
Login
Home
