Tuesday, October 4, 2011

What's wrong with SSL and TLS

Recently, we were asked what our response would be to the BEAST Exploit, a new attack that takes advantage of a vulnerability found by security researchers in the way CBC block ciphers are handled in TLS 1.0 and earlier. Our AccessEnforcer is administered via web interface, and our desktop VPN client, CalyptixVPN, is TLS-based, so it's a legitimate question. The basic answer is this: CalyptixVPN is not vulnerable, and the AccessEnforcer's web interface can be vulnerable in some instances (for example, when a browser doesn't support the RC4 stream cipher), but not when accessed over a VPN connection (either IPSEC or the CalyptixVPN client). Even without a VPN connection, however, the exploit is almost a moot point. Here's why.



First, some background. Most people refer to a secure http session (https) as SSL. As security-focused individuals know, SSL has been insecure for years due to various exploits. In order to maintain compatibility with older browsers, the AccessEnforcer supports this protocol, as well as TLS 1.0, the most recent version of TLS that is widely-supported by browsers. Although TLS is generally more secure than SSL, we now know that in some instances, it can be vulnerable to a CBC block cipher attack (incorporated into BEAST). So if TLS can be broken, why is the exploit a moot point?

First of all, a man-in-the-middle attacker could still proxy the session, break the certificate chain and snoop on the data. If the user doesn't notice the certificate warning, or they are used to accessing sites that use self-signed certificates, they could be the victim of a MITM attack without realizing it.

Secondly, if a country or business deploys their own root CA to every PC, and monitors the internet connection with an edge device that can proxy every secure connection (such as this one from Packet Forensics), they can dynamically generate a certificate for any domain of their choosing, and log (and possibly inject data into) the entire session, all without the user even noticing. In fact, the only clue to the user that she's not communicating directly with the site would only be visible by examining the certificate. But since it still appears to be a secure session and the browser doesn't present a certificate warning, most users wouldn't even think to inspect the cert.


Thirdly, there have been three high-profile hacks this year of certificate authorities: Comodo, DigiNotar, and CA Security, with the hacker claiming that he has now breached even more CAs. At this point, one can only assume that there is at least one hacker out there who can generate a certificate for any domain he chooses, and if he gets between you and your destination, he can snoop on your session. The most promising solution to this problem is called certificate pinning, available via Firefox add-on as well as for Chromium/Chrome, but the majority of internet users are not using these. Even if a security-conscious user attempts to enable certificate pinning, the process is still prone to user error. A browser can't verify that a certificate isn't forged without an authority for it to check against, and there currently is none, so the process is left to the user. Google has hard-coded Chrome to only accept certs from its trusted CAs (incidentally, this is how the fake *.google.com certificate from DigiNotar was discovered), but every other domain is left to the user.


Fourthly, most browsers still support SSL, since some older web servers haven't been updated to support TLS. It turns out that a man-in-the-middle attacker can trigger a fallback to SSL, where TLS would have otherwise been negotiated between the browser and server. This is called a version rollback attack, and an attacker is much more likely to do this, and then utilize an SSL exploit, than attempt to accomplish the more difficult TLS BEAST exploit.

Although browser manufacturers are currently rolling out patches to protect against BEAST, from our perspective, as long as any browser supports fallback to SSL 3.0 or even 2.0, it is vulnerable, regardless of the status of the block cipher bug.

It should be noted that complete details of the BEAST exploit have not been made public, and as far as anyone knows, is not yet in the wild.
It's also worth nothing that as most browsers do not yet support TLS 1.1, we cannot yet force it, and therefore must rely on TLS 1.0 until newer versions are widely supported.

As mentioned earlier, a security-conscious administrator could connect his CalyptixVPN client to the remote AccessEnforcer first (or keep up a persistent IPSEC connection), then connect to the AE via one of its LAN IPs, to ensure that the traffic is routed over the VPN connection. Our VPN uses TLS 1.0, but a workaround prevents it from being vulnerable to this exploit.


Regardless of any vulnerabilities in the protocols themselves, most security researchers believe the "web of trust" certificate system is broken. For now, all we can recommend is to use a browser that is up to date, avoid insecure wifi connections, use a VPN wherever possible, familiarize yourself with certificate pinning, and start getting used to inspecting those certificate chains.