TLS support

[ckrey]

• tcp://host:1883 without TLS works well!
• ssl://host:8883
  OpenSSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
• ssl://host:8886 (tls_verision tlsv1)
  OpenSSL Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
• ssl://host:8887 (tls_verision tlsv1.1)
  OpenSSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
• ssl://host:8888 (tls_verision tlsv1.2)
  OpenSSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

[ckrey]

seems I will have do to some more reading

[ckrey]

Trying SecureConnection

SecureConnection to ssl://host:8883
java.io.IOException: Alert (2,70)
- com.cinterion.imp.io.tls.Record..unknown.(), bci=390
- com.cinterion.imp.io.tls.Handshake..unknown.(), bci=16
- com.cinterion.imp.io.tls.Handshake..unknown.(), bci=8
- com.cinterion.imp.io.tls.Handshake..unknown.(), bci=24
- com.cinterion.imp.io.tls.SSLStreamConnection.<init>(), bci=202
- com.sun.midp.io.j2me.ssl.Protocol.openPrim(), bci=193
- javax.microedition.io.Connector..unknown.(), bci=240
- javax.microedition.io.Connector.open(), bci=3
- javax.microedition.io.Connector.open(), bci=3
- javax.microedition.io.Connector.open(), bci=2
- general.MQTTHandler.connectToBroker(), bci=10
- general.SocketGPRStask.run(), bci=854

on server OpenSSL Error: error:1408F10B:SSL routines:SSL3_CLIENT_HELLO:wrong version number

SecureConnection to ssl://fzvtoshindhfdqqo.myfritz.net:8886
java.io.IOException: TLS: ServerCertificateRequest not implemented
- com.cinterion.imp.io.tls.Handshake..unknown.(), bci=130
- com.cinterion.imp.io.tls.SSLStreamConnection.<init>(), bci=202
- com.sun.midp.io.j2me.ssl.Protocol.openPrim(), bci=193
- javax.microedition.io.Connector..unknown.(), bci=240
- javax.microedition.io.Connector.open(), bci=3
- javax.microedition.io.Connector.open(), bci=3
- javax.microedition.io.Connector.open(), bci=2
- general.MQTTHandler.connectToBroker(), bci=29
- general.SocketGPRStask.run(), bci=854

on server OpenSSL Error: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

[ckrey]

Eyes Opening Article (in German)
http://www.gruntz.ch/courses/sem/ws04/J2MEsecurity.pdf

Will try to work with API Permissions

[ckrey]

Works! (with mosquitto running tlsv1)

Setting API permissions did it:

Jul 28 09:52:49 raspberrypi mosquitto[2167]: New connection from 80.187.109.1 on port 8886.
Jul 28 09:52:50 raspberrypi mosquitto[2167]: New client connected from 80.187.109.1 as 356612027383852 (c1, k30, udt27).
Jul 28 09:52:50 raspberrypi mosquitto[2167]: Sending CONNACK to 356612027383852 (0)
Jul 28 09:52:53 raspberrypi mosquitto[2167]: Received SUBSCRIBE from 356612027383852
Jul 28 09:52:53 raspberrypi mosquitto[2167]: #011owntracks/gw/356612027383852/cmd (QoS 1)
Jul 28 09:52:53 raspberrypi mosquitto[2167]: 356612027383852 1 owntracks/gw/356612027383852/cmd
Jul 28 09:52:53 raspberrypi mosquitto[2167]: Sending SUBACK to 356612027383852
Jul 28 09:53:08 raspberrypi mosquitto[2167]: Received PUBLISH from 356612027383852 (d0, q1, r1, m2, 'owntracks/gw/356612027383852', ... (149 bytes))
Jul 28 09:53:08 raspberrypi mosquitto[2167]: Sending PUBACK to 356612027383852 (Mid: 2)

[jpmens]

W000t!

[ckrey]

Reading wm_java_user_guide_v19.pdf (part of the Cinterion Package) chapter 11.1, I think we have to install the server's ca certificate in the module.

Or, we should assume it works because certificate checking is off:
AT^SJSEC?
^SJSEC: 0, 0, 1, 0

Or, We need certificates with sha1 signature. Java Security supports a sha1 signature of the
certificate only.

[jpmens]

Not in mode1. Mode2 (with CA cert) allows for more trust, but I feel that's
overkill for us at this time. See also 11.2

(The joys of keytool: beings back fond cough memories...)

Have you looked at 11.4.3? This looks very relevant. In particular state=0
and httpsState=0

Don't enable the module's 'secure' mode; that won't end well....

[jpmens]

I obviously have no clue of Java, but I think this is relevant. In any case ignore everything that has to do with signing our app -- we don't want that, at least not yet!

From this:

MIDlets in the MAXIMUM domain are GRANTED ALL PERMISSIONS

The PDF also shows how to do that in Netbeans.

[ckrey]

Re 11.4.3: probably my english is not good enough, but I don't understand: How does the device know if the cert is valid without a list of trusted CAs?

0 The HTTPS connection or Secure Connection is possible if the server certificate (or certificate chain) is valid (default)

and no, I won't enable secure mode

[jpmens]

It just says "if the server certificate is valid". IMO that simply means if it isn't corrupt. There is no mention whatsoever of a valid chain, in other words, it sounds to me as though they won't verify anything, which is fine. Well, sort of fine. :-)

[jpmens]

I've just run AT^SJEC? on my device. Response:

^SJSEC: 0, 0, 1, 0

0 = java security mode not active
0 = HTTPS or secure conn possible if certificate is valid
1 = start of MES permitted
0 = untrusted domain doesn't exist; MIDlets must be signed (I doubt that!)

[ckrey]

same here

Did some testing:

connect to apache2 https (443) works
connect to mosquitto tlsv1 (8887) or tls (8883) does not

What can we do to setup mosquitto to work like apache2

>$secure ssl://x.net:443 GET_/owntracks_HTTP/1.0
ACK: Opening a SecureConnection to ssl://x.net:443
SecurityInfo TLS 3.1
Issuer CN=raspberrypi
Serial 00:DE:FB:4B:74:91:78:FF:5B
SigAlgName SHA1withRSA
Subject CN=raspberrypi
Type X.509
Version 3
Writing GET /owntracks HTTP/1.0
Read (80)HTTP/1.1 301 Moved Permanently
Date: Thu, 31 Jul 2014 11:53:02 GMT
Server: Apac

>$secure ssl://x.net:8887 GET_/_HTTP/1.0
ACK: Opening a SecureConnection to ssl://x.net:8887
IOException TLS: ServerCertificateRequest not implemented

>$secure ssl:/x.net:8883 GET_/owntracks_HTTP/1.0
ACK: Opening a SecureConnection to ssl://x.net:8883
IOException Alert (2,70)

[ckrey]

some more

do we have SH1withRSA algorithm in our mosquitto ssl certs?

>$secure ssl://www.github.com:443 GET_/owntracks_HTTP/1.0
ACK: Opening a SecureConnection to ssl://www.github.com:443
IOException Alert (2,40)

>$secure ssl://mail.google.com:443 GET_/owntracks_HTTP/1.0
ACK: Opening a SecureConnection to ssl://mail.google.com:443
SecurityInfo TLS 3.1
Issuer C=US;O=Google Inc;CN=Google Internet Authority G2
Serial 61:78:FC:43:C5:43:A0:73
SigAlgName SHA1withRSA
Subject C=US;ST=California;L=Mountain View;O=Google Inc;CN=mail.google.com
Type X.509
Version 3
Writing GET /owntracks HTTP/1.0
Read (80)HTTP/1.0 404 Not Found
Content-Type: text/html; charset=UTF-8
Content-Length: 1

[ckrey]

Trying to build gw with current paho library and what they call jmeclient.

Library is dated 2014, while we are using a 2012 version of the code.

New library is build on new Java features like java.util.Properties, which our jdk/jre do not support.

Possibilities:

• can we get a newer version of the sdk from cinterion?
• get really dirty and understand why MQTT over ssl: does not work. As we know, we can connect via
  https: from the gw, so it is not the ssl part, but probably the version of paho. Maybe there is a version of paho which works before it was upgraded java-wise
• look for a java library for mqtt other than paho

[jpmens]

No idea if this'll work, but fusesource say they support TLS

[ckrey]

looks good, but is not suitable for our ancient java version

[ckrey]

Works now, was a small problem in com.m2mgo.net.SSLSocketFactory not overriding the createSocket method of TCPSocketFactory.