Slashdot Mirror
Swiss Researchers Find A Hole In SSL
Kocher, President & Chief Scientist of Cryptography Research, Inc., writes:
The referenced paper (http://lasecwww.epfl.ch/memo_ssl.shtml) describes how timing variations in SSL/TLS implementations can be used in certain situations to slowly gather information about encrypted data. If the certain conditions are met, the attacker can decrypt some information from the message (e.g., a password). Strictly speaking, the fact that implementations reveal sensitive information in timing channels is an implementation issue, not a flaw in the underlying cryptographic protocol. This doesn't make the issue unimportant, however, and timing attacks are big deal for implementers because they are easy to introduce, notoriously tricky to detect, and often difficult to eliminate.
Answers to general questions:
1. Is it still okay to send my credit card number over SSL? Yes. This attack is not applicable to web shopping and there are much easier ways that fraudsters steal credit card information (e.g., breaking into merchants' web sites -- a problem that SSL can't solve). In any case, the bank is generally responsible if someone steals your card info.
2. Is the paper "real" or another bogus "I broke SSL" claim? The paper is legit. The Slashdot announcement suggests that SSL itself is broken, however, which is a bit misleading.
2. Is this a practical attack to exploit? Cryptographers need to be paranoid about unexpected situations. As a result, attacks can be important even if they are not practical to exploit under real- world conditions. The attack described in this paper is similar; while there are quite a few preconditions for mounting the attack, this does not make the research unimportant or mean that people should ignore the work. Specific requirements to mount the attack include:
- The session has to use CBC mode. The vast majority of SSL connections use RC4, for which the attack is not applicable. Because of the algorithm negotiation used in SSL/TLS is secured in the initial handshake, man-in-the- middle attackers should not be able affect the outcome of the algorithm selection process.
- The attacker has to act as an active man-in-the-middle attacker. Passive eavesdropping is not sufficient.
- The server's SSL implementation has to be vulnerable (see #3 below). The protocol also has to be oblivious to repeated failures.
- The target protocol also has to have some very specific characteristics that allow the adversary to form the right kinds of messages. For most uses of SSL (e.g., normal web browsing), this type of attack does not generally apply.
3. Can affected implementations be fixed? Yes. OpenSSL has been updated (http://www.openssl.org/news/secadv_20030219.txt). For more information, also see http://www.openssl.org/~bodo/tls-cbc.txt. I don't know what other vendors/projects are doing.
4. Is this an issue for the client or the server? Normally, this would only be an issue for the "server" (i.e., the party that receives the connection request), since normal SSL clients don't automatically large numbers of connections.
A couple of final comments:
I'm constantly amazed by the number of ways that it's possible to screw up security. Overall, SSL 3.0 seems to have aged well, but I wish I'd done a better job of handling errors in the design. In particular, error handling was involved in both of the attacks against SSL that I consider non-obvious, notably Bleichenbacher's attack and CBC-padding attacks such as this one. While these types of attacks weren't known when I was designing SSL 3.0, I generally wish I'd provided less information in error messages.
Finally, I also want to give thanks everyone who has helped to study SSL's security, contributed to implementations, and helped shepherd it through the standards processes."
The article (the LASEC memo) cites standard, well-known weaknesses in block ciphers. I haven't heard anyone give some of their specifics before (timing attack might be possible with encrypted error messages, for instance), but it's not really a breakthrough.
This looks like a 'man in the middle' attack to me, not so much a failure of ssl.
The details are at best sketchy, anyone else see it this way?
The linked article reports a timing-based attack that could be used to identify passwords when the encrypted message is repeated, as in the case of communicating with an IMAP server. IMAP is not webmail, it is a mail protocol (a popular alternative to POP3) that is frequently secured with SSL/TLS. Once the password is cracked, it could be used to compromise other resources if the IMAP server and those other resources share the same password. It may not be likely that your bank provides your IMAP server, but it is not as unlikely that an IMAP account might share a password with other network functions that you'd want to keep secured...
Trouble making decisions? Just flip for it.
Reading the BBC Article, they totally missed the point of the original article. It's not webmail that is a problem, but TLS/SSL encrypted IMAP or POP3 sessions. No self-respecting web-mail application sends the user-name and password with every screen. Most use a session key after login. It's not a big deal for webmail users, but for those who use TLS to connect to their IMAP/POP servers, it's an open window.
Webmail is insecure because it resends the same data (username & password) regularly to the server. Credit Cards submissions and sign-in pages are unlikely to keep sending the same data repetetively.
Of course, we just need a better webmail application, and you'll be fine.
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
Apparantly the flow only affects webmail and not banking or credit card payments
Technically, the exploit was ideally suited to looking for password information in IMAP/SSL connections, since they are common and frequent. This does not mean the attack is limited to mail-related transactions.
Since most people's passwords are similar/the same for most of their online accounts, in theory, one could use a knowledge of traffic directed at certain sites under other circumstances originating from the same IP to do the same thing. It would take days/weeks instead of hours, but, since most people don't change their passwords that often, it's still conceivable.
This is much less likely to be feasible when it comes to ongoing sessions where the place of authentication is aribtrary (as it is with most e-commerce sites like Amazon and Ebay). However, some sites which use HTTP basic auth (since the username/password are in a well-known location) are now in danger.
What I'm really scared for is the security implication on the new web service protocols which do authentication in a regular, often and predictable way (much like IMAP used in the example), like XML-RPC, SOAP and REST. If SSL is compromised in situations like these, then we've just realized that we're a huge step backward in connection and integration from where we thought we were. At least, that is, until the protocol is fixed (if that's possible).
moto411.com
*) In ssl3_get_record (ssl/s3_pkt.c), minimize information leaked via timing by performing a MAC computation even if incorrrect block cipher padding has been found. This is a countermeasure against active attacks where the attacker has to distinguish between bad padding and a MAC verification error. (CAN-2003-0078)
I interpret this to mean that all implementations of SSL, including OpenSSL, _could_ have this information leakage behaviour, depending on how they are implemented. OpenSSL did happen to have this behaviour, and has now been altered to take the same amount of time in either case, thus not giving the attacker any useful information.
-- There is no truth. There is only Perception. To Percieve is to Exist.
My parents use webmail all the time. They're travel writers and webmail allows them to send and receive mail from anywhere in the world they can gain web access.
For such people webmail can be the difference between having email and not.
That said I'm with you on text mode for mail. It's resource friendly and easy to read. After a few obligitory years of going gaa gaa over WYSIWYG, fonts and white backgrounds I've discovered that, oddly enough, text mode is the ideal method of handly pure text.
Go figure.
KFG
However, it is not an unfixable problem (implementations can avoid the attack if they so choose) and it is certainly not as dire as the BBC article would make it out to be.
Nearly every crypto protocol has 'flaws' such as this, and power-analysis 'flaws', and other sorts of issues which don't involve the protocol itself, but the fact that it has been implemented in a real-world device.
In nearly every case, once an attack like this becomes known, the response should be simply "so don't implement it like that anymore". The protocol itself doesn't actually change.
Living better through chemicals
Imagine that the fuel pump in your car breaks down. You need to get somewhere and don't have the parts to fix the fuel pump, but you do a good stock of odd stuff lying about. So you take a bottle, some hose, and a coat hanger, fill the bottle with gasoline, run the hose into it and hang the lot from your dome light, allowing gravity to feed fuel to the carb. (Yes, I've actally done this. It's a real world example).
Or, your boat has a hole in the hull, so you dive overboard, throw some canvas and underwater putty over it, and go on your way.
Your car and boat are still broken and require repairs of their fundamental structure, but, for the moment, can be considered as functioning normally.
One can kludge software in a like manner at times.
This is one of those times.
KFG
Actually a cookie such as you describe might well be vulnerable to a leaky-cipher problem like this one, since the HTTP headers are reasonably large, uniformly located (in part because of the punctuated way HTTP is used between browser and server), and generally much the same for subsequent requests. It seems this would probably be worse for, say, RC4 (for the same sorts of reasons as WEP is breakable).
This is why the cookie is only good for a session and has a short timeout. You may be able to grab some candy, but you can't steal the whole store.
Those are examples of crypto protocols that were designed by non-cryptographers. SSL/TLS does not fall into that category. Those vulnerabilities were due to very stupid key derivation algorithms ("let's add three to the last RC4 key and use that...").
SSL's use of a PRF to generate the key material gets around the RC4 key derivation problems present in WEP and in PPTP. The last couple of SSL protocol problems have had to do with block ciphers. RC4 would have protected you in all cases; both this one, as well as an arlier theoretical result about mac-then-encrypt security protocols.
You're wrong.
The only information leaked to the attacker is the amount of time elapsed between sending the bogus packet and getting the error response. The attacker can't decrypt the error response without having the key. The ONLY change in OpenSSL is that it performs a redundant check so that the same amount of time will elapse in either case. This is 100% compatable with the spec.
no. much the same way that one woman can make a single baby in nine months, but nine women can't make one baby in one month.
it's the amount of traffic generated that takes time, and you want to camp outside a server to see enough traffic to break the key.
ashridah
I wouldn't say that at all. DNS spoofing is sadly still feasible in many situations and easily gives you this capability. It is trivial if the attacker is on the same layer 2 network (insider attacks are extremely common, and so are outsiders who own one machine on the network and then leverage that for more.) Remember that the SSL certificate validation process won't protect you from this attack, since that part of the protocol is proxied through unmolested.
-Fyodor
Concerned about your network security? Try the free Nmap Security Scanner
Indeed eithernet (even switched) is susceptible to a problem where a gratuitous arp is sent (from the bad guy's computer) that causes a machine (victim's computer) to think an IP address (eg the gateway) maps to an incorrect MAC address (the bad guy's NIC).
:(
Last year a few friends got together and tested ettercap out (in a controlled environment) and sure enough it's trivial to snoop on a machine's traffic.
FYI, Netscape fixed this bug in NSS in 1998. No Netscape or Sun SSL servers released since then have been vulnerable to the attack as a result.
This is merely a problem in OpenSSL, and it doesn't affect SSL in general.
-- Julien Pierre http://www.madbrain.com/blog