Can SSL and TLS be made Compatible?
We are sometimes asked if there is any way to make SSL and TLS be compatible with each other. On the surface, this may seem almost nonsensical, but there are cases where such a question actually makes sense!
SSL (Secure Sockets Later) and TLS (Transport Layer Security) are fundamentally the same form of encryption – see SSL versus TLS – what’s the difference. But if that is the case, doesn’t that make them automatically compatible? Well, not really.
How are SSL and TLS Used?
SSL and TLS are used to secure communications over the Internet, e.g. POP, IMAP, SMTP, Web site traffic, Exchange ActiveSync traffic, API connections, and much more. Their use helps ensure that you are connecting to the proper servers and that the communications are not eavesdropped upon.
The actual encryption mechanisms are used by SSL and TLS are the same; however, the difference relates to how the encryption is initiated.
- SSL: With a server expecting an SSL connection, it expects the user’s computer to start negotiating security immediately … nothing can happen until the SSL connection is established and the mechanism of establishing SSL is the same no matter what will go through that secure connection once it is established.
- TLS: With TLS, the server expects an unencrypted connection from the user’s computer with the computer “speaking the language” of whatever service it is trying to talk to (e.g. SMTP to send outbound email). Before anything sensitive is said, your computer can specify commands in that language to start negotiations to make the communications channel encrypted (e.g. with SMTP, your computer would issue the “STARTTLS” command and then dialog with the server to get things encrypted). Once encryption is established, all the important things like your username, password, and data are sent across safely and securely.
So with SSL, you talk security first, business second. With TLS, you start talking business first, but its small talk. You talk security second and then important business third. The level of security is the same and the important business is protected in both cases.
So, why are they not compatible?
If you have a program that can only talk SSL, say, and not TLS but you need to connect to a service that only supports TLS … you can’t do it. Your program wants to talk security first; their system wants to do service specific small talk first. They don’t jive.
A good example might be an outbound email program that can do TLS on port 25 (the standard SMTP port) and SSL on alternate ports (like 465) but which was never made so it could do TLS on alternate ports. Old versions of Microsoft Outlook had this quirk. If you could not connect to port 25 because your ISP was blocking you and you needed to connect securely to an alternate port, you’d better hope there was one with SSL support, because you would not be able to connect securely to an alternate TLS port.
If there any way to make them compatible?
Well, there is no way to make a “square” SSL peg connect to the “round” TLS hole or vice versa. At least, not without putting some kind of adapter in between.
The simplest solution when you need to connect to a remote server that support SSL is usually to use a program like “stunnel“. This is a program that acts like an adapter:
- It runs on your local computer or server.
- It establishes a connection using SSL to a remote system that talks SSL (it doesn’t matter for what protocol).
- You connect your software insecurely to the local stunnel server. E.g. you connect without SSL or TLS, but that is OK since you are connecting from your computer to itself.
- Your communications then go securely from your computer to the remote server over SSL due to the stunnel connection.
This works great if your program can connect without SSL or TLS and the remote server uses SSL. It is trickier if you need to connect to a TLS-only server and your program only supports SSL. There is no good simple solution for this case except for possibly:
- Updating your program to one that supports TLS.
- Contacting the service provider to see if they have any alternate SSL-supporting ports.
- Using a different provider that supports SSL.
LuxSci supports many standard and non-standard ports to address these restrictions.