Community
Participate
Working Groups
Reported by: alexrhelder@outlook.com The Paho Java client does not perform peer verification on the connected socket. This allows peer spoofing / MITM attacks. Proposed Solution #1 Like HttpsURLConnection, the IMQTTClient interface could get something like the following: void setHostnameVerifier(HostnameVerifier hv); where Java5 built-in HostNameVerifier interface is either reused as-is or inspires a Paho equivalent. http://docs.oracle.com/javase/1.5.0/docs/api/javax/net/ssl/HostnameVerifier.html Proposed Solution #2 Instead of SSLNetworkModule / TCPNetworkModule creating a disconnected socket via SocketFactory.createSocket(), use SocketFactory.createSocket(String hostname, int port) A custom SSLFactory implementation could look like: class MySSLSocketFactory { SSLSocketFactory delegate; SSLSocket createSocket(String hostname, int port) throws IOException { SSLSocket s = delegate.createSocket(hostname, port); s.startHandshake(); verifyHostName(s, host); } void verifyHostName(Socket s, String host) { // Throw exception if fail verification } } In any case, I think the Paho client should not create a disconnected socket; this allows the SSLSocketFactory to apply alternative settings and policies on the created socket. Note: Java 7 has X509ExtendedTrustManager which is a connection-sensitive trust manager. This may also be leveraged in the future, but is relatively new.
Al disagrees on the seriousness of this bug report, don't you Al? (And whether it is truly a vulnerability)
I do :) In that it depends on your use case, If you're deploying an app that will talk to known servers over SSL you will preseed your trust store with only the certificates relevant to the systems you wish to connect to and the lack of hostname verification doesn't seem to be a problem. That's not to say I think we shouldn't make this an option anyway.
So, this is a worthwhile enhancement, but not a vulnerability.
<alsm> what's the vulnerability? You have to steal the private key first to do anything with it. <alsm> once you've done that you can already decrypt the communications <g00s> i need to review it again. but if a mitm is possible (and i'm not hallucinating) it seems very serious to me. this in conjunction with the likely scenario that mqtt will often be used in IoT scenario, where updating clients may be difficult because they are in remote locations or the sheer number of them <alsm> you can't mitm just because we don't do cn checking <alsm> you'd have to redirect the client and have stolen a private key that the client would verify <alsm> these devices are not going to be webservers/clients. I would very much not recommend putting the whole swathe of root CA certs on them <ral> 13:15 < alsm> these devices are not going to be webservers/clients. I would very much not recommend putting the whole swathe of root CA certs on them <ral> This is a point worth repeating. <g00s> OK, sounds good, i'm getting rusty at this topic already, its so tricky <g00s> if its been reviewed, thats good <alsm> But it will be added to the client Once the J2ME codebase is split off into its own repository we can utilise language features > 1.4.2 and implement the HostNameVerifier interface.
I noticed this is marked for v0.5 but according to https://projects.eclipse.org/projects/technology.paho/releases/1.1.0/bugs the next release will be v1.1.0 Will this be fixed or will there be a workaround so we are able to do hostname verification ?
Reassigning to Bin.
Reassiging back to me.
Migrated to GitHub Issue: https://github.com/eclipse/paho.mqtt.java/issues/38
Migrated to GitHub Issue: https://github.com/eclipse/paho.mqtt.java/issues/74
Moved to Github
