Discussing a new attack on SSL/TLS
I thought I’d take the opportunity to focus on something different for this post, we’re going to look at a recently announced attack against SSL/TLS called “CRIME”.
To bring you up to speed, SSL (Secure Sockets Layer) is the original protocol that secures your connection whenever you use a URL beginning with “https://” in your browser. Various flaws have been discovered over time, and SSL has been updated to fix them. TLS (Transport Layer Security) is the successor to SSL and is largely similar in implementation. Out of familiarity, many people still refer to TLS as SSL.
While details of CRIME are yet to be released (it’ll be publicised at Ekoparty, an upcoming Security Conference), it follows on from an earlier attack called BEAST from the same researchers and there are educated guesses as to how it’ll work.
One such guess has been made on the security-related StackExchange board. The writer freely admits that it’s conjecture, but the explanation they provide is comprehensive and appears well-founded based on my own education. Whether that’s how CRIME actually works will be revealed soon enough, but we’ll assume that it’s correct for the sake of discussion.
Outline of CRIME
The overall model of the attack is straightforward: assuming the attacker can hijack the network between the victim and the target website (eg. Gmail), the goal is to steal a cookie for a login session. With this cookie, the attacker can impersonate the victim as though they were logged-in.
The interesting bit here is how the cryptography is broken. On paper it’s very secure, but information can be leaked if compression is used as part of the protocol. By hijacking the victim’s browser and making many requests to the server, the attacker can inspect the encrypted data and see how its behaviour changes very slightly. This is called a chosen-plaintext attack. By doing this they can guess the contents of the victim’s cookie, one character at a time.
CRIME sounds like an interesting attack, and entirely plausible. As things go I wouldn’t expect it to completely break encryption on the web, but it opens up a lot of problems. The suggested workaround, to disable compression, sounds sufficient.
As described, the attack isn’t completely trivial because it assumes being able to get code into the user’s browser (exploiting stuff like cross-site request forgery). It also requires the attacker to monitor traffic along the path between the victim and the target server, which is a fair amount of effort. This isn’t Hollywood, it’s practically impossible for some anonymous script kiddie to pick you as a victim and sniff your traffic from the other side of the world.
There’s a certain amount that all involved parties can do, so we considered how CRIME might affect us in the datacentre, and it looks like there’s a certain risk factor.
Assuming that one of our customers is a high-value target doing lots of e-commerce transactions, the network is a potential weak point (remembering that the attacker needs to sniff network traffic). Getting a server on the same network segment is possible, but not easy for the attacker to “steer”. Once they have a server, they need root access on the operating system to sniff traffic, and then likely need to go unnoticed by our security systems. This is certainly possible.
In terms of risk assessment, our customer can take some solace in the fact that such servers with root access are comparatively rare – Anchor does a lot of fully managed hosting where the customer doesn’t get root privileges. This reduces the attack surface. In addition, a security-concious customer has the option of private network segments that would make such an attack much more difficult.
Or course there are defensive measures available, like disabling compression as suggested. That’s unfortunate, but effective. Hardening browser security may also show some gains here, along with stricter security checking on website.
For now we’re eagerly awaiting the details from Ekoparty.