Noose around Internet’s TLS system tightens with 2 new decryption attacks

[Aerosol]

The noose around the neck of the Internet's most widely used encryption scheme got a little tighter this month with the disclosure of two new attacks that can retrieve passwords, credit card numbers and other sensitive data from some transmissions protected by secure sockets layer and transport layer security protocols.

Both attacks work against the RC4 stream cipher, which is estimated to encrypt about 30 percent of today's TLS traffic. Cryptographers have long known that some of the pseudo-random bytes RC4 uses to encode messages were predictable, but it wasn't until 2013 that researchers devised a practical way to exploit the shortcoming. The result was an attack that revealed small parts of the plaintext inside an HTTPS-encrypted data stream. It required attackers to view more than 17 billion (234) separate encryptions of the same data. That was a high bar, particularly given that the attack revealed only limited amounts of plaintext. Still, since the researchers demonstrated the attack could decrypt HTTPS-protected authentication cookies used to access user e-mail accounts, Google and other website operators immediately took notice.

Now, researchers have figured out refinements that allow them to recover RC4-protected passwords with a 50-percent success rate using slightly more than 67 million (226) encryptions, a two-order of magnitude reduction over the previous attack used to recover secure cookies. The exploits—laid out in a paper published last week titled Attacks Only Get Better: Password Recovery Attacks Against RC4 in TLS—work against both Basic access authentication over HTTPS and the widely used IMAP protocol for retrieving and storing e-mail.

Bar-mitzvah attack

A second exploit targeting RC4 was devised by researchers from security firm Imperva and was presented Thursday at the Black Hat security conference in Singapore. The attack uses new ways to exploit the "invariance weakness," a key pattern in RC4 keys that can leak plaintext data into the ciphertext under certain conditions. The weakness first came to light in 2001, and led to the fatal exploit against wired equivalent privacy technology used to encrypt Wi-Fi networks. Given the age of the invariance weakness, Imperva researchers are dubbing their new exploit the "bar-mitzvah attack."

"The security of RC4 has been questionable for many years, in particular its initialization mechanisms," Imperva researchers wrote in a research paper that accompanied Thursday's Blackhat talk. "However, only in recent years has this understanding begun translating into a call to retire RC4. In this research, we follow [the 2013 RC4 researchers] and show that the impact of the many known vulnerabilities on systems using RC4 is clearly underestimated."

The bar-mitzvah attack requires adversaries to sample about one billion RC4 encryptions to infer a credit card number, password, or authentication cookie key. The known weakness exploited involves a flaw found in one out of every 16 million (224) RC4 keys that leads to "structures" in the "least significant bits" of the keystream. The attack is subject to a significant limitation, however, since the leaky plaintext is contained only in the first 100 bytes of ciphertext. Despite the limitation and the challenge of sampling so many encryptions, the attack may be enough to drastically reduce the cost of doing an exhaustive attack that guesses passwords, credit card numbers or similar data. Rather than try every possible combination, the bar-mitzvah attack allows attackers to hone in on a much smaller number of candidates.

The growing body of attacks that defeat SSL and TLS encryption are only one threat facing the system millions of Internet users rely on to encrypt sensitive data and authenticate servers. In 2011 hackers broken into Netherlands-based certificate authority DigiNotar and minted counterfeit credentials for Google and other sensitive Web properties. Earlier this week, shoddy practices at an intermediate CA known as MCS Holdings, allowed its customers to obtain unauthorized certificates for several Google addresses. Poor practices on the part of Microsoft also led to the discovery of misissued certificates, on two separate occasions.

“RC4 must die”

The TLS protocol has two significant phases. The first "handshaking" phase uses asymmetric encryption to negotiate the symmetric encryption keys to be used by an e-mail or Web server and the connecting end user. During the later "record" phase, the parties use the agreed-upon keys to encrypt data using either the AES block cipher or RC4 stream cipher. The two attacks unveiled this month, combined with the exploit disclosed in 2013, are a strong indication the security of RC4 can't be counted on for much longer and should be phased out in favor of alternative algorithms.

Retiring RC4 is proving a challenging proposition. A 2011 attack known as BEAST—short for Browser Exploit Against SSL/TLS—targets an encryption mode known as CBC, or cipher block chaining, which is present in most algorithms except for RC4. After BEAST was demonstrated to pose a credible threat to TLS-protected data in transit many security experts recommended website operators opt for RC4 to blunt the threat. That advice is no longer sound, now that RC4 is under attack, too.

Imperva researchers say Web app developers should strongly consider disabling RC4 in all their TLS configurations and tech-savvy end uses should disable RC4 in their Browser settings. In February, the Internet Engineering Task Force submitted a request for comments prohibiting the use of RC4 cipher. Use of RC4 has shrunk from about half of all TLS traffic in 2013 to about 30 percent today, but eliminating it altogether may take years. Hanging in the balance, is the security and confidentiality of millions of Internet users.

"RC4 was already looking nervously towards the cliff-edge," Kenny Paterson, a Royal Holloway, University of London professor who helped author last week's research, as well as the 2013 research it built on, wrote in a blog post published last week. "Our work pushes RC4 a significant step closer, leaving it teetering on the brink of oblivion for SSL/TLS. After all, attacks can only get better…"

Source