In-Depth
Debunking 6 Myths about SSL VPN Security
Think VPN makes for secure data access and transfer? Think again.
Even though the OpenSSL Toolkit has been hacked 44 times since 2002, VPN solutions continue to heavily rely on this technology. In fact, some of the most high-profile security breaches have involved SSL VPNs. This begs the question: are users not using the technology correctly, or is SSL simply not as good as all the marketing hype makes it out to be?
This year alone, several incidents have surfaced that call into question the security of SSL platforms, such as Comodo issuing nine fraudulent certificates affecting several domains and the recent breach at Dutch digital certificate authority DigiNotar, among others. Clearly, confusion exists about the security capabilities of SSL. Ultimately, this misinformation undermines the technology and lessens its appeal in scenarios where SSL is an ideal solution. This article puts the most persistent SSL myths to rest and clarifies the technology’s capabilities -- and its limitations.
Myth #1: Using trusted certificates from a certificate authority (CA) is airtight.
It’s this assumption that that got DigiNotar and Comodo into some hot water this year. In reality, certificates -- even those from a CA -- are certainly not airtight. Certificates used to authenticate an SSL connection allow for the certain identification of each party and for the negotiation of an encrypted channel for communication. The certificates themselves are files whose alteration can be easily detected and whose origin is verified by a trusted certificate authority (such as Comodo or VeriSign).
Web application developers use this trusted-certificate model extensively when building their applications. The problem is that the CA can be spoofed. Electronic Frontier Foundation staff technologist Peter Eckersley recently published an in-depth analysis demonstrating that Iranian hackers acquired fraudulent SSL certificates for Google, Yahoo, Mozilla, and others by spoofing Comodo. CAs sell digitally signed certificates that browsers use to verify their network connections, but with these spoofed certificates, the hackers could undetectably impersonate Yahoo and Google -- allowing them to read e-mail even if it was being read over a secure connection. The Mozilla certificate would allow them to slip malicious spyware onto the computer of anyone installing a Firefox plug-in.
HTTPS and other SSL-using protocols (secure SMTP, POP, IMAP, Jabber, and many others that build on SSL) still offer protection against casual snoopers. They’ll protect against the use of Firesheep in a hipster café just fine. However, the trust and security promises implicit in the use of SSL -- and which many people depend on -- are promises that CAs simply cannot keep.
Myth #2: Sensitive information transfer via SSL sessions is secure.
Although companies often use SSL to secure sensitive information transfer from customers or partners, but vulnerabilities in this approach are frequently exposed. For example, a recent attack targeted CitiGroup’s 21 million customers and resulted in a 1 percent success rate. This might seem low, but remember it translates to 210,000 compromised users.
Even worse, the CitiGroup breach wasn’t an isolated case. Swiss researchers recently published a memo describing a way to gather information about the data transmitted over an SSL channel by exploiting a vulnerability in the implementations of block ciphers such as AES. It’s worth noting that AES was developed by Defense Advanced Research Projects Agency (DARPA) and is widely accepted as the strongest form of encryption. The memo, however, pointed out that in certain circumstances, it’s possible to decrypt some of the data in the messages, including encrypted passwords. This vulnerability is linked to the way error handling is implemented in applications that use the cipher-block chaining mode, such as AES in SSL. One of the best ways to avoid this pitfall is to never use the same key stream to encrypt two different documents.
The cipher-block chaining also exhibits well-known weaknesses that can be exploited to break SSL communication. Just how easy it is to crack SSL/TLS was demonstrated recently by two researchers, Thai Duong and Juliano Rizzo. They demoed a straightforward attack against SSL/TLS using a Java Applet to decrypt -- or even take over -- a SSL/TLS secured session. The man-in-the-middle (MITM) access required for this attack is typically obtained either from network insiders (and the majority of network attacks are attributed to insiders) or by intruders breaking into weakly secured wireless LANs, for example, from a parking lot or company lobby. The attack only pertains to TLS 1.0 which is still the most prevalent version in all common browsers -- a fact that, again, outlines the importance of effectively controlling the client-side of VPN communications (for example, by deploying managed VPN clients).
Of course, there are numerous ways an attacker can mount a successful attack against the Web browser -- too many to name in this article. If you’re interested in more details, the Open Web Application Security Project (OWASP) is a good resource.
Myth #3: HTTPS is a secure pipe.
In the CitiGroup breach, the security of thousands of customers was compromised because of the faulty assumption that they were using a secure pipe. People assume if a pipe is connected directly to the Internet through the Internet service provider’s (ISP) network, it must be safe -- especially in conjunction with the Windows firewall and anti-virus software typically used to connect (or pipe) to the Internet.
However, IPv6 allocates addresses that are theoretically all routable through the Internet. This might expose someone to a threat, particularly if the firewall isn’t set up correctly. It is also worth noting that IPv6 tunneling allows a path through IPv4 firewalls. With this, attackers might be able to penetrate a network if the IPv6 firewall is not set up properly. Of course, this particular nuance of IPv6 tunneling is not obvious unless you have an advanced network engineering background.
Myth #4: One-way certificate authentication of a SOA Web service is secure because it uses HTTPS.
SOA’s simplicity lies in its use of descriptor-based definitions of application transactions that can be articulated directly from a business process into a service. Because SOA uses Web-based technology, it is convenient to use SSL as the mechanism to secure user sessions. Yet SSL can be used to tunnel any application-level protocol, which would be otherwise run on top of TCP in the communications protocol stack. The most common use nowadays is to secure the HTTP communication vis-a-vis HTTPS, in which case the user’s browser is not authenticated -- only the server side is authenticated by SSL. This is known as one-way SSL authentication. Yet, there are known man-in-the-middle (MITM) attacks that have been successful against this authentication scheme for at least 10 years.
Myth #5: Two-way certificate exchange between a SOA Web service and a client can always be trusted.
SSL achieves its security by using certificates to authenticate each side of a connection made between two parties: the Web server and the client (usually a Web browser), both of which are based on public key cryptography. The SSL protocol assumes that if a public key can be used to decrypt a piece of information, it's all but certain that the information was originally encrypted with the corresponding private key.
When initiating a two-way SSL session, the client will check that the SOA Web service certificate is valid and signed by a trusted entity. The server running the Web service publishes a certificate -- a little chunk of data that includes a company name, a public key, and some other bits and pieces -- and when the client connects to the server, the client sends the server some information encrypted using the public key from the certificate. The server then decrypts this using its private key. Once the connection is established, all information during that session is encrypted with this information.
Since only the server knows the private key -- and hence, only the server can decrypt the information encrypted with the public key -- this allows the client to prove that it is communicating with the rightful owner of the certificate. Herein also lies the flaw.
To defeat this setup, the MITM just has to do a bit more work and create its own certificate with a private / public key pair and sit between the client and server. Thus, it would be acting as a server to the client and a client to the server -- and listening in on everything sent between the two.
Bringing Clarity to SSL
Ultimately, these myths have contributed to staggering vulnerabilities that have undermined people’s trust and confidence in all network security protocols. The only way forward is to untangle SSL’s capabilities from its limitations -- without the marketing haze and distortions.
This article is based on a whitepaper Debunking the Myths SSL VPN Security, written by Rainer Enders and Clint Stewart. You can contact Rainer Enders at rainer.enders@ncp-e.com