Community
Participate
Working Groups
Dear Eclipse Security team, I noticed the following bug in mosquitto: when configuring the broker in order to implement TLS but without certificate-based authentication and any of the PSK keywords (configuration provided below), mosquitto clients are wrongly allowed to connect (and interact) by providing random PSK values (key and identity) without specifying the --cafile parameter. According to the documentation, the client is required to specify the right CA certificate in order to connect (--cafile and, if using self-signed certificates, the --insecure parameters in mosquitto_pub). With a valid but not right certificate, the connection is correctly denied. Below are indicated the allowed requests of the mosquitto client (user is provided to respect the "allow_anonymous false" parameter in configuration): -> mosquitto_pub -h "ip_addr" -t "test" -p 8883 -i "id-1" -m "ok" --psk "deadbeef" --psk-identity "psk-test" -u "user1" -> mosquitto_pub -h "ip_addr" -t "test" -p 8883 -i "id-1" -m "ok" --cafile cert/ca.pem --insecure -u "user1" Here an example of few correctly denied requests: -> mosquitto_pub -h "ip_addr" -t "test" -p 8883 -i "id-1" -m "ok" --cafile cert/wrong_certificate.pem --insecure -u "user1" -> mosquitto_pub -h "ip_addr" -t "test" -p 8883 -i "id-1" -m "ok" -u "user1" -P "password1" Component: mosquitto 1.5.8 (latest) and mosquitto_pub 1.4.15 (latest) OS: Linux (Ubuntu 18.04) and Docker image eclipse-mosquitto:latest This is the configuration used: ########CONF listener 8883 allow_anonymous false cafile cert/.... certfile cert/..... keyfile cert/...... tls_version tlsv1.2 #require_certificate true -> to avoid client certificate-based authentication #####################
Thanks for the report. I need to look into this a bit more, but at first glance this is a bug in the clients only. Setting certificate based encryption on the server side is just a means of providing encryption and assurance that you are connected to the correct host (assuming the client verifies the host name they are connecting to with the host name in the certificate returned - it is this check only that --insecure disables). It does nothing at all in terms of client authentication. When you try to connect with an invalid CA certificate, it is the client that refuses to connect it is not the server that refuses the connection. What we have in the scenario you describe is that the client connects and doesn't ask for a certificate, so it doesn't try to verify the server (this is one disadvantage of TLS-PSK). This is entirely expected. The client and the server are able to negotiate a shared encryption scheme. The surprising part is that the client is happy to carry on even without the PSK scheme completing, presumably. This is the part that needs looking into. At the moment I don't believe the server is misbehaving, but I'll be checking that as well.
Any progress?
Nothing concrete so far. All the testing I've done suggests that other systems behave in the same way, but TLS-PSK isn't that widely used so it isn't easy to say for sure. I've got a more complicated test to put together which should answer an important question I have.
The Eclipse Foundation's policy requires the disclosure of vulnerabilities after 90 days. I've removed the committers-only flag.
That's fine, I still don't see what can be done here, or even that is necessarily a problem. The server is configured to enable encryption, but not with TLS based authentication (i.e. TLS PSK) The client is configured to enable encryption, and to try to use PSK for authentication. The authentication isn't required by the server, but the client is still able to negotiate encryption. So the issue appears to be that a client attempts to connect using one type of authentication, but the server doesn't require that type of authentication, so the connection succeeds. The client is likewise configured to not care about checking the server certificate, so that check isn't made.
That sounds reasonable to me. I recommend that you resolve this as either INVALID or WONTFIX.
Thanks for the advice Wayne.
