Entries Tagged "TLS"
Page 2 of 2
About 0.2% of all SSL certificates are forged. This is the first time I’ve ever seen a number based on real data. News article:
Of 3.45 million real-world connections made to Facebook servers using the transport layer security (TLS) or secure sockets layer protocols, 6,845, or about 0.2 percent of them, were established using forged certificates.
EDITED TO ADD (6/13): I’m mis-characterizing the study. The study really says that 0.2% of HTTPS traffic to Facebook is intercepted and re-signed, and the vast majority of that interception and resigning happens either on the user’s local computer (by way of trusted security software which is acting scanning proxy) or locally on a private network behind a corporation’s intercepting proxy/firewall. Only a small percentage of intercepted traffic is a result of malware or other nefarious activity.
This is a really clever attack on the RC4 encryption algorithm as used in TLS.
We have found a new attack against TLS that allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used. The attacks arise from statistical flaws in the keystream generated by the RC4 algorithm which become apparent in TLS ciphertexts when the same plaintext is repeatedly encrypted at a fixed location across many TLS sessions.
The attack is very specialized:
The attack is a multi-session attack, which means that we require a target plaintext to be repeatedly sent in the same position in the plaintext stream in multiple TLS sessions. The attack currently only targets the first 256 bytes of the plaintext stream in sessions. Since the first 36 bytes of plaintext are formed from an unpredictable Finished message when SHA-1 is the selected hashing algorithm in the TLS Record Protocol, these first 36 bytes cannot be recovered. This means that the attack can recover 220 bytes of TLS-encrypted plaintext.
The number of sessions needed to reliably recover these plaintext bytes is around 230, but already with only 224 sessions, certain bytes can be recovered reliably.
Is this a big deal? Yes and no. The attack requires the identical plaintext to be repeatedly encrypted. Normally, this would make for an impractical attack in the real world, but http messages often have stylized headers that are identical across a conversation—for example, cookies. On the other hand, those are the only bits that can be decrypted. Currently, this attack is pretty raw and unoptimized—so it’s likely to become faster and better.
There’s no reason to panic here. But let’s start to move away from RC4 to something like AES.
This is an extremely clever man-in-the-middle timing attack against TLS that exploits the interaction between how the protocol implements AES in CBC mode for encryption, and HMAC-SHA1 for authentication. (And this is a really good plain-language description of it.)
It’s the Browser Exploit Against SSL/TLS Tool, or BEAST:
Using the known text blocks, BEAST can then use information collected to decrypt the target’s AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.
The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0which would be most secure sites, since follow-on versions of TLS aren’t yet supported in most browsers or Web server implementations.
While Rizzo and Duong believe BEAST is the first attack against SSL 3.0 that decrypts HTTPS requests, the vulnerability that BEAST exploits is well-known; BT chief security technology officer Bruce Schneier and UC Berkeley’s David Wagner pointed out in a 1999 analysis of SSL 3.0 that “SSL will provide a lot of known plain-text to the eavesdropper, but there seems to be no better alternative.” And TLS’s vulnerability to man-in-the middle attacks was made public in 2009. The IETF’s TLS Working Group published a fix for the problem, but the fix is unsupported by SSL.
EDITED TO ADD: Good analysis.
Firesheep is a new Firefox plugin that makes it easy for you to hijack other people’s social network connections. Basically, Facebook authenticates clients with cookies. If someone is using a public WiFi connection, the cookies are sniffable. Firesheep uses wincap to capture and display the authentication information for accounts it sees, allowing you to hijack the connection.
Slides from the Toorcon talk.
Protect yourself by forcing the authentication to happen over TLS. Or stop logging in to Facebook from public networks.
EDITED TO ADD (10/27): To protect against this attack, you have to encrypt the entire session—not just the initial authentication.
EDITED TO ADD (11/17): Blacksheep detects Firesheep.
I’m in Gaithersburg, MD, at the Cryptographic Hash Workshop hosted by NIST. I’m impressed by the turnout; a lot of the right people are here.
Xiaoyun Wang, the cryptographer who broke SHA-1, spoke about her latest results. They are the same results Adi Shamir presented in her name at Crypto this year: a time complexity of 263.
(I first wrote about Wang’s results here, and discussed their implications here. I wrote about results from Crypto here. Here are her two papers from Crypto: “Efficient Collision Search Attacks on SHA-0” and “Finding Collisions in the Full SHA-1 Collision Search Attacks on SHA1.”)
Steve Bellovin is now talking about the problems associated with upgrading hash functions. He and his coauthor Eric Rescorla looked at S/MIME, TLS, IPSec (and IKE), and DNSSEC. Basically, these protocols can’t change algorithms overnight; it has to happen gradually, over the course of years. So the protocols need some secure way to “switch hit”: to use both the new and old hash functions during the transition period. This requires some sort of signaling, which the protocols don’t do very well. (Bellovin’s and Rescorla’s paper is here.)
Sidebar photo of Bruce Schneier by Joe MacInnis.