{"action":"opened","issue":{"url":"https://api.github.com/repos/eclipse/paho.mqtt.java/issues/38","repository_url":"https://api.github.com/repos/eclipse/paho.mqtt.java","labels_url":"https://api.github.com/repos/eclipse/paho.mqtt.java/issues/38/labels{/name}","comments_url":"https://api.github.com/repos/eclipse/paho.mqtt.java/issues/38/comments","events_url":"https://api.github.com/repos/eclipse/paho.mqtt.java/issues/38/events","html_url":"https://github.com/eclipse/paho.mqtt.java/issues/38","id":131345256,"number":38,"title":"The Paho Java client does not perform peer verification on the connected socket","user":{"login":"jpwsutton","id":1068763,"avatar_url":"https://avatars.githubusercontent.com/u/1068763?v=3","gravatar_id":"","url":"https://api.github.com/users/jpwsutton","html_url":"https://github.com/jpwsutton","followers_url":"https://api.github.com/users/jpwsutton/followers","following_url":"https://api.github.com/users/jpwsutton/following{/other_user}","gists_url":"https://api.github.com/users/jpwsutton/gists{/gist_id}","starred_url":"https://api.github.com/users/jpwsutton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jpwsutton/subscriptions","organizations_url":"https://api.github.com/users/jpwsutton/orgs","repos_url":"https://api.github.com/users/jpwsutton/repos","events_url":"https://api.github.com/users/jpwsutton/events{/privacy}","received_events_url":"https://api.github.com/users/jpwsutton/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-02-04T13:22:11Z","updated_at":"2016-02-04T13:22:11Z","closed_at":null,"body":"migrated from Bugzilla [#425195](https://bugs.eclipse.org/bugs/show_bug.cgi?id=425195)\nstatus REOPENED severity *enhancement* in component *MQTT-Java* for *1.2*\nReported in version *1.1* on platform *PC*\nAssigned to: Ian Craggs\n\nOn 2014-01-09 09:26:26 -0500, Ian Craggs wrote:\n\n> Reported by: alexrhelder@outlook.com\n> \n> The Paho Java client does not perform peer verification on the connected socket. This allows peer spoofing / MITM attacks.\n> \n> Proposed Solution # 1\n> \n> Like HttpsURLConnection, the IMQTTClient interface could get something like the following:\n> \n> void setHostnameVerifier(HostnameVerifier hv);\n> \n> where Java5 built-in HostNameVerifier interface is either reused as-is or inspires a Paho equivalent.\n> \n> http://docs.oracle.com/javase/1.5.0/docs/api/javax/net/ssl/HostnameVerifier.html\n> \n> Proposed Solution # 2\n> Instead of SSLNetworkModule / TCPNetworkModule creating a disconnected socket via\n> \n> SocketFactory.createSocket(), use SocketFactory.createSocket(String hostname, int port)\n> \n> A custom SSLFactory implementation could look like:\n> \n> class MySSLSocketFactory {\n> \n>     SSLSocketFactory delegate;\n> \n>     SSLSocket createSocket(String hostname, int port) throws IOException {\n>         SSLSocket s = delegate.createSocket(hostname, port);\n>         s.startHandshake();\n>         verifyHostName(s, host);\n>     }\n> \n>     void verifyHostName(Socket s, String host) {\n>         // Throw exception if fail verification\n>     }\n> }\n> \n> 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.\n> \n> Note: Java 7 has X509ExtendedTrustManager which is a connection-sensitive trust manager. This may also be leveraged in the future, but is relatively new.\n\nOn 2014-01-09 09:36:26 -0500, Ian Craggs wrote:\n\n> Al disagrees on the seriousness of this bug report, don't you Al?  (And whether it is truly a vulnerability)\n\nOn 2014-01-09 09:49:18 -0500, Al Stockdill-Mander wrote:\n\n> 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.\n> \n> That's not to say I think we shouldn't make this an option anyway.\n\nOn 2014-04-22 10:50:27 -0400, Ian Craggs wrote:\n\n> So, this is a worthwhile enhancement, but not a vulnerability.\n\nOn 2014-05-01 10:03:19 -0400, Al Stockdill-Mander wrote:\n\n> <alsm> what's the vulnerability? You have to steal the private key first to do anything with it.\n> <alsm> once you've done that you can already decrypt the communications\n> <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\n> <alsm> you can't mitm just because we don't do cn checking\n> <alsm> you'd have to redirect the client and have stolen a private key that the client would verify\n> <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\n> <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\n> <ral> This is a point worth repeating.\n> <g00s> OK, sounds good, i'm getting rusty at this topic already, its so tricky\n> <g00s> if its been reviewed, thats good\n> <alsm> But it will be added to the client\n> \n> Once the J2ME codebase is split off into its own repository we can utilise language features > 1.4.2 and implement the HostNameVerifier interface.\n\nOn 2014-11-10 07:14:52 -0500, Davy De Waele wrote:\n\n> 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\n> \n> Will this be fixed or will there be a workaround so we are able to do hostname verification ?\n\nOn 2015-02-02 11:52:01 -0500, Ian Craggs wrote:\n\n> Reassigning to Bin.\n\nOn 2015-07-09 07:29:17 -0400, Ian Craggs wrote:\n\n> Reassiging back to me.\n\n"}}