Does anyone know what protocol version the SSL library on the ConnectPortX use?
I’m trying to connect to an SSL socket on a java server. I’ve tried both TLS and SSLv3. Either way I get a handshake error. I’ve looked through the digi python docs and the python docs for 2.4.3 and I can’t find any info on what protocol is used.
In the stack trace I see references to the SSLv23 and SSLv3 protocols:
Traceback (most recent call last):
File “./socket.py”, line 74, in ssl
sslerror: (1, ‘error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure’)
I have not tried direct SSL for years, but for sure SSL v3.0 or TLS v1.0 should work - most tools now default to trying to force v3.1/1.1 which mainly add better “reporting of issues”, which is part of good cyber-forensics.
It is also possible you are asking for ciphers which the Digi won’t support - AES is best since it is optimized for digital CPU crunching (unlike DES, which is optimized for hardware and burdensome for a CPU)
For my Python on PC to Digi SSL tests I use the tlslite python module, and I have this code: self.ssl_tls = TLSConnection( self.sock)
sets = HandshakeSettings()
sets.cipherNames = [ “aes128”, “aes256”]
sets.minVersion = (3,0)
self.ssl_tls.handshakeClientCert()
So I force python (on my PC) to use SSL v3.0 and AES
Which SSL or security library are you using to do this? I’ve seen implementations in socket, tlslite, and OpenSSL, which all have different methods of specifying which protocol versions to use.
Currently there is no way in 2.4.3 to change the connection method and the only one attempted is SSLv23. We do plan on migrating to Python 2.6 in an upcoming release. The ssl module in that release allows the selection of the handshaking method.
Bob, I had a talk with some security people, if there is any way to tell/config the Java server to only talk 3.0 but to not become “upset” if the Digi offers to talk as either 2 or 3, then you’ll be okay (so server change).
As said above, 2.6 on the Digi will solve this.
tlslite is a big package (despite the name - I’ll be interested if it works, but my gut feeling is that it includes OS-specific hooks since Python 2.4 doesn’t provide a full SSL API exposure.
The tlslite 0.3.8 which I use on a PC (from trevp.net/tlslite) is 496K on the disk, 363K in pure files. A lot of the files won’t be required on a simple “SSL/TLS tunnel”.
When I include this library along with the other libraries I am using it runs the X2 out of disk space.
It also tries to load some pretty memory hungry libraries (e.g. xml.dom.) that I’ve already removed because of memory issues. I’m doubtful the memory would have held up even if there was disk available.
This is going to be more work than I had hoped. It looks like I’ll have to make the built in ssl library work. As far as I can tell my options are:
Wait for Python 2.6 (not really an option. I have a deadline in 2 weeks)
Run an SSL proxy in front of my Java server.
Install a third party SSL provider for the JVM (I haven’t looked at this deaply but I think it is a but ugly)
Any other ideas? I’m kind of leaning toward option #2