Even for regular end users, SSL is one of the most widely-recognized VPN protocols, largely due to the fact that major VPN vendors such as SonicWall and Cisco have been using it in their proprietary protocols for years.
In this post, we take you through the origins of SSL, including how it works and why it was developed, and also explore some of the key pros and cons to be aware of when opting for this protocol.
How did SSL come to exist?
There are protocols that are always encrypted, like SSH (Secure Shell Protocol). Most protocols, however, are not encrypted at all, like HTTP (Hypertext Transfer Protocol). Wouldn't it be great, if you could turn every unencrypted protocol into an encrypted protocol without having to change the protocol itself or any of the protocols running below it? That's what Netscape Communication thought when they released a protocol named SSL (Secure Socket Layer) in 1994.
Based on earlier work that had already been started in 1986 as part of the Secure Data Network System (SDNS), Netscape added this protocol to their Mosaic web browser – the first widely distributed web browser in history and the fourth web browser that has even been written since the idea of the World Wide Web was born.
What is SSL?
SSL is a protocol layer that sits in between a transport protocol like TCP and a higher level application protocol layer like HTTP.
From the perspective of a software developer, a normal connection to the remote host is established but instead of directly starting to talk HTTP over that connection, a SSL handshake is first performed to authenticate the remote site. Following this, a method and keys for data integrity protection and data encryption are negotiated and all further communication is wrapped into SSL records that are protected against manipulation and encrypted prior to sending.
The name SSL is derived from the fact that a network connection in most systems is represented by an object called "a socket" and SSL would turn this socket into a secure socket, which, once the SSL handshake is done, would behave pretty much like a regular socket. Ultimately, this means neither developers nor a protocol like HTTP need to regard SSL being used, as the developer just uses a SSL library and the protocol doesn't even notice that it is there.
How does SSL work?
SSL is what turns HTTP into HTTPS. In fact, HTTPS simply means "HTTP over an SSL connection". But SSL is not limited to HTTP; it can be used with pretty much all protocols that would otherwise directly use TCP, including FTP (FTPS), IMAP (IMAPS), POP3 (POP3S), SMTP (SMTPS), SIP (SIPS), and so on. For this to work, none of the protocols need to be adapted. Both sides of the connection simply need to agree that they will use an SSL connection over TCP instead of just a raw TCP connection.
That means SSL can be implemented as an afterthought, and it can even be implemented through a local proxy service, so the original software without built-in SSL support could still use SSL without any modification. For example, there were some very good but dated NNTP clients that never received SSL support (active development had been stopped years ago), however, by setting up a local SSL proxy, it was possible to connect them to servers that would only support NTTPS.
The history of SSL versions
Only 5 months after version 1, SSL version 2 was released. Back in 1995, when Microsoft released Internet Explorer, they implemented their own protocol as an alternative to SSL (as they always do.) This protocol was named PCT (Private Communication Technology).
PCT offered a few enhancements in comparison to SSL 2, which Netscape then addressed by adding them to SSL version 3 in 1996. Version 3 would be the last SSL version Netscape ever released before they handed over the controls to the IETF (Internet Engineering Task Force) to turn SSL into a real standard protocol to avoid something like PCT happening again.
What is the IETF?
The IETF is the standard organization that also standardizes IP, TCP, HTTP and pretty much all the widespread, vendor-neutral internet protocols.
The introduction of TLS
One of the first things the IETF did was rename the SSL protocol, as "socket" is a term used only by programmers when talking about networking; meaning not even every operating system or network library would be familiar with that term. Instead, they named the protocol TLS (Transport Layer Security) and since it now had a new name, versioning would restart at 1.0 but TLS 1.0 is essentially just SSL 3.0 with a few minor modifications.
The IETF published many extensions to TLS 1.0: TLS 1.1 was released in 2006, 1.2 in 2008 and TLS 1.3 in 2018 (which still is the current version as of today.)
Since March 2020, TLS 1.3 is the only version of the standard that Firefox, Chrome, Edge, and Safari still support. Despite the name change happening 27 years ago, the name SSL has somehow stuck and even today people sometimes say SSL when referring to TLS. This is also true for SSL VPN protocols, (e.g. SonicWall SSL) which all in fact use TLS despite their name.
"What if we take entire network packets, not just their payload, and send them over a TLS connection? It provides authentication, data integrity, and encryption, so basically we are all set. All we then need to do is extract the packets back at the other end and release them into the network."
The result was the birth of a whole family of SSL VPN protocols.
One common mistake users make is to assume that SSL VPN itself already describes a protocol, which is far from the reality. All SSL VPN protocols are incompatible with each other for three major reasons:
1. TLS is not designed to handle packets but to handle a stream of data. To turn packets into a stream of data and back into packets at the other end, they need to be wrapped into some slim wrapper protocol and every vendor developed their own wrapper protocol, either from scratch or based on an already existing protocol.
2. TLS provides server authentication (e.g. when you open a HTTPS connection, the web server will authenticate to you) but it does not provide client authentication.
Technically TLS can authenticate clients, just like it can authenticate servers using certificates, so a user could authenticate towards a web or mail server with a client certificate, this is just rarely used in practice. However, what about logging in with a username and password or providing an OTP code? TLS itself doesn't offer anything for those cases, as that's usually performed by the protocol running on top of TLS (e.g. HTTP or IMAP have client authentication as part of the protocol) and again, every vendor is doing their own thing when it comes to client authentication. They either perform it as part of the wrapper protocol or in a separate step prior to even establishing the VPN tunnel itself.
3. If you want dynamic configuration provisioning, e.g. assigning IP addresses or remote networks to clients, this either needs to be part of the wrapper protocol, or it needs to happen before the connection has been established – either as part of authentication, or even in a completely separate step. And just as before, different vendors use different methods for that.
So SSL VPN is not actually SSL VPN and despite all using SSL as their base, the following protocols are in no way compatible with each other:
- SonicWALL SSL VPN (*)
- Fortinet Fortigate SSL VPN (*)
- Cisco AnyConnect (*)
- Microsoft SSTP (*)
- Juniper SSL VPN
- Pulse Connect Secure
- Palo Alto Networks GlobalProtect SSL VPN
- F5 Big-IP SSL VPN
- Array Networks SSL VPN
Connecting to SSL VPN in VPN Tracker
Protocols with an asterisk at the end are supported by VPN Tracker as of today, yet their level of support may vary. Note that most of these protocols are proprietary and neither standardized nor documented, with the exception of SSTP, which at least is publicly documented.
What about OpenVPN?
If you’re wondering where OpenVPN is in that list, OpenVPN is special, as it does use TLS but not as part of the VPN tunnel itself. TLS in OpenVPN is only required for certificate authentication and key exchange (deriving dynamic session keys), both of which are optional features. TLS is not used for encrypting the tunneled traffic itself, so OpenVPN cannot really be seen as an SSL VPN protocol.
Pros and cons of SSL VPN protocols
TCP usage
One downside of SSL protocols is that SSL is designed to run over TCP and, as we’ve already covered, TCP is a very bad choice for VPN protocol.
As an alternative, some SSL VPN protocols do offer DTLS tunneling (e.g. AnyConnect and FortiGate), but that's always optional. DTLS is a variant of TLS that is designed to work with packets ("Datagrams", hence the D) instead of a data stream. This at least solves the TCP issue for these protocols, as long as client and server both support the optional DTLS tunneling and are also able to use it, which may be limited by firewalls blocking non-TCP traffic.
Still, DTLS is usually inferior to other VPN protocols designed for this task from the ground up, since DTLS also was not designed to be a VPN protocol.
Network compatibility
A clear advantage of SSL VPN is its compatibility in most network locations. An SSL VPN connection running over port 443 can easily pass as a HTTPS web connection, since they are both indistinguishable from one another. This is particularly useful, as hardly any firewall will block HTTPS connections, meaning SSL VPN connections will most likely work in network locations where other VPN protocols (e.g. IPsec) are blocked by the local firewall.
Security (or lack thereof)
On the other hand, this can also quickly turn into a disadvantage, as it also means that many security firewalls will try to break the TLS tunnel, since security vendors developed the rather bad habit to intentionally break TLS connections using a man-in-the-middle (MitM) attack, in order to look into the transported data and scan it for malware or other undesired data transmissions.
Firewalls can act as a 'Man-in-the-Middle' and check data being transmitted between the user and the VPN gateway
While this sounds like a good idea at first, it also destroys data integrity protection and the level of privacy an encrypted connection is able to provide, and that is a bad idea.
Regular users cannot distinguish a well meant MitM attack from an evil MitM attack – i.e. phishing attacks where an attacker just wants to steal passwords, credit card numbers, or trade secrets.
Cyber attackers can also use MitM attacks to intercept data between the end user and the VPN gateway. In most cases, users can't tell the difference
Of course such an "attack" does not go unnoticed, TLS is protected against it and the client informs the user (using a certificate warning) however, in the end, the users often have little choice: They can allow the attack to happen, in that case the VPN is no longer secure and protected, or they can deny it, but then the firewall may block the connection completely, leaving the user with no VPN at all.
Browsers, VPN clients, etc. warn users when a potential attack is taking place
The only way to tell the difference between attacks is if users have initially been given a certificate by a trusted person (e.g. the IT administrator), which they first need to have manually installed and trusted on their device for all SSL VPN connections.
How do Man-in-the-Middle attacks work?
For all MitM attacks, the firewall acts like the VPN gateway to the user and like the user to the gateway. That way, it can decrypt all the data in the middle and re-encrypt it without either side noticing.
The one thing a MitM attack cannot do is fake the gateway certificate used for TLS server authentication. Instead, it must replace this certificate with its own one, which the client will notice and warn the user about. The client is then given the option to either trust this "incorrect certificate" or not.
Unless trusted, the TLS handshake will stop immediately and no TLS connection can be established.
Is this problem unique to TLS?
Of course, a similar attack is also possible with other VPN protocols, but firewalls are usually only designed to break TLS and will thus leave other VPN protocols alone.
Moreover, this is only possible if authentication is certificate-based and certificates are exchanged on the fly during connection establishment, as is the case with TLS.
If certificates or keys are exchanged prior to that (e.g. via config distribution, as is the case for WireGuard® or OpenVPN), or if the authentication is based on a different method, like a pre-shared secret (e.g. IPsec using pre-shared keys), there is no way a firewall could break into that without possessing the configured certificates/keys or shared secret. It goes without saying that this is a highly unlikely scenario, as VPN 101 states only trusted endpoints should have access to this information.
New to VPN Tracker?
Start your free, 7 day VPN Tracker trial today to test all the latest features.
