Researchers have devised two new attacks on the Transport Layer Security and Secure Sockets Layer protocols, the widely used encryption schemes used to secure e-commerce transactions and other sensitive traffic on the Internet.
The pair of exploits—one presented at the just-convened 20th International Workshop on Fast Software Encryption and the other scheduled to be unveiled on Thursday at the Black Hat security conference in Amsterdam—don't pose an immediate threat to the millions of people who rely on the Web-encryption standards. Still, they're part of a growing constellation of attacks with names including BEAST, CRIME, and Lucky 13 that allow determined hackers to silently decrypt protected browser cookies used to log in to websites. Together, they underscore the fragility of the aging standards as they face an arsenal of increasingly sophisticated exploits.
"It illustrates how serious this is that there are so many attacks going on involving a protocol that's been around for years and that's so widely trusted and used," Matthew Green, a professor specializing in cryptography at Johns Hopkins University, told Ars. "The fact that you now have CRIME, BEAST, Lucky 13, and these new two attacks within the same week really illustrates what a problem we're facing."
The most serious of this week's attacks exploits weaknesses in RC4, a stream cipher that researchers estimate is used to encrypt about 50 percent of the world's TLS traffic. Cryptographers have long known of flaws in RC4. Specifically, some of the pseudo-random bytes the cipher used to encode messages were predictable. But until now scientists hadn't devised a practical way to exploit the shortcoming.
A team from Royal Holloway, University of London, and the University of Illinois-Chicago has discovered that the small "biases" contained in RC4 can be manipulated in a way that reveals a limited amount of the plaintext in an encrypted data stream. It requires attackers to receive tens of millions of different encryptions of the same message. By statistically sampling them, the lack of randomness can be exploited to deduce parts of the encrypted message.
"Some of us have been worried for quite a while that RC4 was becoming the dominant cipher of choice in TLS," Royal Holloway scientist Kenneth G. Paterson told Ars. "We knew that RC4 had significant problems. What we didn't know was how to exploit them in TLS. Now we do. Vendors and users are on notice: this attack is only going to get stronger."
Because only small parts of message can be decrypted, the attack works best against ciphertext that contains known strings in a fixed location, such as authentication cookies.
"Unfortunately, if your connection is encrypted using RC4 (as is the case with Gmail), then each time you make a fresh connection to the Gmail site, you're sending a new encrypted copy of the same cookie," Green wrote in a blog post describing the attack. "If the session is renegotiated (i.e., uses a different key) between those connections, then the attacker can build up the list of ciphertexts he needs."
The number of TLS key renegotiations in the typical Web session is vastly insufficient to satisfy the tens of millions of encryptions attackers need. The scientists—who include Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering, and Jacob Schuldt—have therefore proposed that JavaScript working with a man-in-the-middle attacker can rapidly generate all the encrypted connections needed for the attack. A man-in-the-middle position is when the attacker has a connection between the two parties and the ability to monitor or even tamper with the messages sent back and forth.
It’s about TIME
This week's other TLS attack is also able to read HTTPS-protected login credentials when end users transmit them to Web servers. The so-called TIME exploit—short for Timing Info-leak Made Easy—is in some respects a refinement of the CRIME attack that successfully decrypted HTTPS-protected browser cookies used to access user accounts on Github.com, Dropbox.com, and Stripe.com. That earlier exploit worked when both the targeted website and browser used the Google-spawned SPDY protocol or TLS compression to reduce the number of bytes contained in a file or data stream by removing redundant information. By guessing the contents of an encrypted payload character by character and then analyzing whether the compressed ciphertext grew or shrank in size, researchers Juliano Rizzo and Thai Duong were able to slowly decipher the contents.TIME works in a similar fashion. It uses JavaScript that forces a browser to send multiple requests to an online bank or other website that uses TLS. But rather than measure the number of bytes contained in the encrypted request sent by the end user, TIME measures the time it takes for websites to respond with responses that have been both encrypted and compressed. Responses that are faster will on average contain fewer bytes, allowing attackers to know that the plaintext contained in a particular guess was also contained in the encrypted data stream. By forcing a victim browser to send hundreds or thousands of requests and comparing subtle differences in the time it takes for the website to respond, the TIME attack decrypts the payload character by character until all of the contents are revealed.
"The attacker no longer needs to be an eavesdropper," Tal Be'ery, Web security research team leader at security firm Imperva, said of the TIME attack he helped develop. "The attacker can just lead the victim to his site and from that point onward the attacker only needs to apply certain JavaScript to get the victim's secret data."
Most of the previous exploits on TLS require the attacker to have a "man-in-the-middle" position. When combined with the CRIME techniques, TIME has no such restrictions. It's also potentially more effective than either the Lucky 13 or the other attack from this week because it requires hundreds of thousands of requests, rather than tens of millions or hundreds of millions.
Be'ery said the vulnerability TIME exploits resides more in browsers than in TLS itself. Specifically, the problem lies in a bedrock security principle known as the same origin policy. It prevents cookies and most other content set by one domain from being able to read or modify data from another domain. The researcher said the policy should be extended to prevent timing attacks.
"Just as the browser doesn't let JavaScript directly get the size of the request or the response to other sites... it should stop the timing information from leaking, because it enables the attacker to infer on the secret information," he told Ars. "It shouldn't be allowed to do so. Browsers need to have some mechanism for the server to say 'I don't want to give any information about this specific resource. I don't want to let it be timed.'"
Not enough Band-Aids
Given the hurdle of collecting vast numbers of encrypted packets, it's unlikely either of this week's attacks—or last month's Lucky 13 exploit, for that matter—will have much practical application right away. But as new techniques are developed and new vulnerabilities are discovered, the attacks are likely to improve and may at some point overcome the resistance TLS has so far shown in withstanding the string of new exploits. Ironically, a chief reason for the large concentration of RC4-protected TLS traffic was its ability to withstand BEAST attacks. Now that"It's not totally clear what can be done," Green told Ars, referring to a reliable fix for the Web encryption standards. "In the short term, we have better versions of TLS and we're not using them for a bunch of silly reasons, mostly to do with backward compatibility. Browser companies and people who make servers really need to get on this and they need to start moving to new versions and TLS. They need to do it soon, before these attack become really practical."
沒有留言:
張貼留言