SSL/TLS Implementation Vulnerability
Ryan Pierce / Townsend Analytics Ltd. / Archipelago LLC
21 Feb 2003 1:06PM ET
I've recently learned of an implemented successful attack against SSL/TLS, documented here:
http://lasecwww.epfl.ch/memo_ssl.shtml
First, this attack is not intrinsic to the protocol itself. Only flawed implementations of the protocol are vulnerable. OpenSSL, the target of this attack, was vulnerable, but a patch was recently released to fix it.
Second, I don't think this attack is terribly applicable to FIX.
SSL/TLS must be used with a cipher in CBC mode for the attack to occur, i.e. DES or Triple DES. Using RC4 gets around this problem, however RC4 is a trade secret requiring a license while DES is free, so I would expect most open-source products in the US to use Triple DES rather than RC4.
The attack works as follows:
1. Alice connects to Bob, but Mallory intercepts the connection surreptitiously and sits in the middle.
2. Alice sends a block of data over SSL/TLS. Mallory knows enough about the structure of the data to guess where a key piece of info, like a password, will be placed.
3. Mallory makes a guess at the password, modifies the incoming block based on that guess, and sends it to Bob.
4. Bob will detect the modified block, send an error back to Alice (through Mallory), and drop the session. The error will either be a padding error or a MAC error.
5. The error message is encrypted, so Mallory can't see it directly. But Mallory measures the time Bob took to send the error, and from that, infers whether it was a padding or MAC error.
6. Based on the type of error returned, Mallory has learned whether the guess was close to the password.
7. Alice sees the connection has dropped and connects to Bob again. (And Mallory intercepts it.) Mallory makes another guess, gets information on the correctness of that guess, and the connection drops. This is repeated until Mallory knows the entire password.
Now if Bob was smart, he'd make sure he spends the same amount of time to send back either error message. In this case, Mallory gains no useful information. If Alice was smart, she'd realize that her connections keep mysteriously dropping, and investigate.
Why I don't think this poses a severe threat to FIX:
1. There isn't valuable info to be gained by this kind of attack. It *DOESN'T* allow an attacker to steal either party's private key, or even the session key that would allow decryption of all messages within a session. All it allows an attacker to do is to steal a piece of info that is repeated in the same place during each connection attempt. FIX doesn't have any kind of valuable "password" in the Logon. Going through this kind of trouble to steal a CompID or BeginString is hardly worthwhile.
2. Because it actively disrupts the session, it only works if a reconnect is automatically attempted, and only then if either party doesn't notice the repeated drops, stop what they are doing, and investigate.
What was successfully exploited was an IMAP mail client communicating over SSL/TLS with an IMAP server. Mail clients are ideal for this kind of attack because they poll servers repeatedly, and the logon message they send contains a password in the same place.
Other fprotocols relying on CBC mode SSL/TLS that contain a repeated sensitive piece of info in a predictable place, and that will reconnect and retry operations automatically, may be vulnerable if their SSL/TLS implementation takes differing times to respond to MAC vs padding errors.
