SSL Tcp Socket Protocol Version

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 “./”, 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)

So I force python (on my PC) to use SSL v3.0 and AES

In digging futher it would seem as though Python is using the SSLv23 protocol by default.

The problem being that I’m using a Java socket server and newer JVMs don’t support SSLv2 at all. Just SSLv3 and TLSv1. So basically I can’t connect.

So to revise my question: can I force the ssl protocol in Python to be SSLv3 or TLSv1 instead of SSLv23?


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.

I’m using the built in ssl method from the socket library:

import socket

s = socket.socket()
ss = socket.ssl(s)

… use socket here …


It sounds like it is SSLv23 only…

Maybe I’ll give tlslite a try.

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 :slight_smile: - 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 is 496K on the disk, 363K in pure files. A lot of the files won’t be required on a simple “SSL/TLS tunnel”.

So… The tlslite is pretty much a non-starter.

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:

  1. Wait for Python 2.6 (not really an option. I have a deadline in 2 weeks)

  2. Run an SSL proxy in front of my Java server.

  3. 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

I’m not sure what is really out there for SSL tunnels so I just installed stunnel (the first one returned by Google search).

It is using OpenSSL under the covers. I’m connecting to it from the gateway and then it is proxing to my server.

Works like a charm! Thanks for all your input.