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.
