Slashdot Log In
Swiss Researchers Find A Hole In SSL
from the there's-holes-in-everything-over-there dept.
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."
Ugh... (Score:5, Funny)
Isn't that their style?
Yeah, I know, that joke was cheesey.
Re:Ugh... (Score:3, Funny)
Did anyone else read that as "Swiss Researchers Find A-Hole In SSL" and think, "How did he get there?"
Re:Ugh... (Score:3, Funny)
-fren
Wait... (Score:3, Interesting)
Also, the hole was "passed on to the developers, and will be fixed in the next version of the software." So what, is this just some particular implementation of the SSL protocol? Is it MS', OpenSSL's, whose?
Re:Wait... (Score:5, Insightful)
Of course, we just need a better webmail application, and you'll be fine.
Parent
Wow (Score:4, Insightful)
The Swiss (Score:5, Funny)
OpenSSL new version has fix already (Score:5, Informative)
Released yesterday: http://www.openssl.org [openssl.org]
Re:OpenSSL new version has fix already (Score:5, Informative)
This is possible because SSL implementations typically abort processing a message immediately if the padding is incorrect, without testing the MAC, meaning that they respond a couple of milliseconds sooner than they would have if the padding was correct.
The openssl countermeasure is simply to perform a MAC test in all cases, whether the padding was correct or not, before returning an error to the client.
Parent
BASIC? (Score:2, Funny)
RFC 2617 explains HTTP Basic Authentication (Score:3, Informative)
Of course its insecure, they programmed their security in basic.
Those of us who wonder what the "basic" in HTTP's "basic authentication" really stands for should read RFC 2617 [ietf.org].
A different kind of SSL? (Score:3, Interesting)
Um? Well, are they talking about 64 vs 128 bit keys? The article later indicates it's a weakness in sending the same password often within one session, which would be actually, an implementation problem as opposed to an SSL problem. Anyone have a mirror of the actual paper and not ust the bbc article yet?
(got to the whitepaper) (Score:2)
I thought the article was already
Re:A different kind of SSL? (Score:5, Informative)
This cookie would be vulnerable (it gets sent with each request) except that each HTTP request is formed with a fair amount of variance in it. More data goes back and forth (requests for HTML files, graphics files, etc) so there isn't that one little message being sent many many times.
Again, RTFA. The problem comes from the same message being crypted and sent again and again. This is why only very specific things are vulnerable.
Parent
Re:A different kind of SSL? (Score:3, Insightful)
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.
Re:A different kind of SSL? (Score:3, Informative)
Most people here seem to be latching on to this quote, as well as the one on the swiss site which mentions that other web-based services using SSL may also be vulnerable, and assuming that a contradiction exists.
By "a different type of SSL," they may be referring to the SET protocol that machines use when communicating directly with credit card companies. It's been a long time since I looked at SET authentication, but it may not be vulnerable to this sort of attack.
I can imaging the BBC reporters learning this, through talking to the researchers, and eventually coming up with that line, which implies that e-commerce sites over SSL are safe (which is very likely wrong)
But what if I'm a repetitive compulsive buyer? (Score:5, Funny)
Re:But what if I'm a repetitive compulsive buyer? (Score:3, Funny)
That's why eBay is still in business...
Heise and OpenSSL developers tells the opposite (Score:5, Informative)
Heise says: "OpenSSL developers already reacted and issued versions 0.9.7a and 0.9.6i of openssl, which close this security flaw. In a posting on bugtraq they recommend this update for all users." (translation done by me).
I have read the bugtraq announces as well, they specifically state that the update DOES fix this bug. So it is NOT a bug in the SSL protocol itself, but in the implementation, at least regarding to OpenSSL developers.
It's a floor wax. No, it's a dessert topping. (Score:3, Informative)
The flaw is in the protocol. OpenSSL has produce a security patch in *their implimentation* that protects the hole in the protocol, but the flaw in the protocol remains.
All other implimentations that have not been so patched remain vulnerable.
KFG
Re:It's a floor wax. No, it's a dessert topping. (Score:5, Informative)
Obviously this is wrong. The OpenSSL developers were able to fix the problem WITHOUT breaking compability to other SSL implementations. So how can this be a problem with the protocol itself, if it can be fixed without actually altering the protocol?
This does not make real sense.
Parent
Definitely floor wax. (Score:3, Insightful)
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.
More from OpenSSL changelog (Score:5, Insightful)
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.
Parent
Re:Heise and OpenSSL developers tells the opposite (Score:5, Informative)
The bug in the protocol is that the RFC says that for block cipher decryption errors, you should report a "decryption failed" alert but for MAC errors you should report a "MAC error" alert. This opens you up to attacks.
A good implementation will report "MAC error" in both cases, and take the same amount of time to do that reporting in both cases (this is what OpenSSL's fix does). This doesn't follow the RFC but it shuts down this avenue of attack.
So OpenSSL is safe and the Heise was overstating things in a very misleading way.
Parent
Re:Heise and OpenSSL developers tells the opposite (Score:3, Funny)
> an ebuild for OpenSSL 0.9.6i [gentoo.org].
And in a few weeks when Gentoo is done compiling you'll be able to use it!
An Hour... (Score:2, Funny)
banking too (Score:5, Informative)
The article didn't make that claim, and in fact says:
Huh? We must not have read the same article... (Score:5, Insightful)
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...
Phew! (Score:3, Funny)
flaw is easily avoidable; use RC4 (Score:5, Informative)
This measure can be taken on the client side by setting your browser's SSL preferences. All good SSL-enabled browsers (Mozilla, Opera, etc.; basically anything except IE) will let you disable non-RC4 ciphers for SSL. Turn off RC2, DES, 3DES, and AES. Only leave RC4 suites (or C4 suites as they are called in Opera).
This measure can be taken on the server side by configuring your web server's SSL configuration to only support RC4 cipher suites (RC4 is the only stream cipher defined in SSL).
If you are using OpenSSL, they made a new release (0.9.6i and 0.9.7a) yesterday that prevents this attack from working. Basically, they made the new code take identical amounts of time for the block decryption failure vs. the MAC failure which thwarts the timing attack described by LASEC. Even their old code has been smart enough to report the same error on the wire, but the old code had a timing difference (block error would skip the MAC computation).
This is not the end of the world. This is not an insurmountable flaw in the SSL protocol (although they really shouldn't have specified block decryption error as one of the alert types in the first place).
Just use RC4 for now and upgrade your web servers when you can.
Re:flaw is easily avoidable; use RC4 (Score:5, Informative)
So for this specific case I would personally run away from RC4 like hell.
Also, in order to do this attack the attacker has to a be a man in the middle with capability to intercept and replace traffic. Outside the scope of a university campus network the possibility for such attack is becoming a very rare occurance as most networks do not have a suitable point to do this without exposing yourself.
Parent
Re:flaw is easily avoidable; use RC4 (Score:3, Insightful)
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.
Re:flaw is easily avoidable; use RC4 (Score:4, Insightful)
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 [insecure.org]
Parent
Re:flaw is easily avoidable; use RC4 (Score:3, Informative)
For those of you who are concerned that ssh may be vulnerable (I don't know... it probably won't matter unless you have an automatic process like rsync or fetchmail using ssh to re-connect over and over on a regular basis), you can use "arcfour" as the "Cipher" parameter in openssh. To force this, create a ".ssh/config" file in your home directory with these lines in it:arcfour is known to have security problems with protocol version one, so it's not supported there (or was not last I looked, but that was a Changelog entry from 20000509).
Good luck.
Flaw is in OpenSSL implementation, not protocol (Score:5, Informative)
The fix is pretty trivial, the second error check is done even if the first fails, thus removing any time based information (i.e. data takes about the same time to traverse both checks whether it fails the first or second one), thus denying the attacker the needed information. Fixed versions of OpenSSL have already been released. For more information please see OpenSSL Security Advisory [19 February 2003] [openssl.org].
As a further note the BBC article is wrong, the quote "It is the first time we have noticed a security problem in the SSL protocol itself and not in how we use it or how we implement it" is either a misquote or flaw. If the flaw were in the protocol itself the solution would not consist of a 30 line patch to OpenSSL's error checks.
protocol is slightly flawed (Score:5, Insightful)
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.
Parent
Only affects IMAPS? (Score:3, Insightful)
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).
From bugtraq (Score:5, Informative)
"The attack assumes that multiple SSL or TLS connections involve a common fixed plaintext block, such as a password. An active attacker can substitute specifically made-up ciphertext blocks for blocks sent by legitimate SSL/TLS parties and measure the time until a response
arrives: SSL/TLS includes data authentication to ensure that such modified ciphertext blocks will be rejected by the peer (and the connection aborted), but the attacker may be able to use timing observations to distinguish between two different error cases, namely block cipher padding errors and MAC verification errors. This is sufficient for an adaptive attack that finally can obtain the complete plaintext block."
Read the full advisory at:
http://www.openssl.org/news/secadv_20030219.txt [openssl.org]
Webmail? (Score:4, Informative)
The description is a little misleading with the webmail and not cc info. If I sent my CC info across a SSL session many times, it would be just as bad as an email password.
Although, if I sent my CC info across any session more than once, I would be asking for it anyways.
Note: Gentoo and Entrust have already released updated packages for users to install. It will not be long until RedHat, SuSE, and others do as well.
Differences Between Post and Article? (Score:3, Interesting)
"Quoting Professor Serge Vaudenay from a BBC article the security problem is in 'the SSL protocol itself and not in how we use it or how we implement it.'"
This is different from what it says in the LASEC memo [lasecwww.epfl.ch], which identifies a timing attack as necessary to distinguish MAC errors from PAD errors. This suggests that if random delays are added to the error messages, the vulnerability disappears. The article also mentions (obligatory?) that the hole has been fixed in OpenSSL 0.9.7a, which clearly means that the vulnerability is implementation-dependent.
"Apparantly the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack."
The LASEC article does not mention webmail at all, it talks about MicroSoft Outlook connecting to an IMAP server as a convenient example of a situation where the attack is fairly easy to carry out. The point is that the information that is being sent is the same every time, so that multiple guesses can be made. Additionally, in the example, Outlook connects to the server and sends the password every 5 minutes, so that multiple guesses can be attemted in a reasonably limited time span. This means that an attack is feasable for services like email, where the same information is transmitted frequently, and harder for services where the frequency is lower, e.g. SSH sessions.
just my thoughts, I'm not a security expert - yet.
---
All generalizations are false.
SWISS CHeesE (Score:5, Funny)
Did you know that they invented Donut Holes as well. No Actually a man names James Vindenhaffer broke into the Duncan Donuts research facility and went through all of the garbage. He first tried to glue all the Holes together to make new donuts but after being frustrasted with their odd shapes decided to leave a good thing untouched.
This is where Jamie BrickenHymer took over. After buying a holeless Donut from a Donut shop in Clevland Ohio he wondered where all the other Donut Holes went. Little did he know that he was being bugged by Micrsoft. 3 Days later Microsoft had the patent for the Donut Hole and sold the Rights to Dunkin Donuts for 43 Billion Dollars.
Giggle. (Score:4, Funny)
Q: Is it still okay to send my credit card number over SSL?
A: Yes, after last weekend everyone already knows your credit card number anyway, so don't worry about it.
Re:Arg!!!! (Score:5, Informative)
Besides which, openssl 0.9.7a was released yesterday, and it addresses these issues.
Parent
Re:SSL mail (Score:3, Funny)
I figure this flaw won't affect them till maybe 2015 when they decide that IMAP might be the way to go.
(shrug)
Re:SSL mail (Score:5, Informative)
It's long been obvious that periodic mail checks are a great sniffing opportunity for credentials (especially since many people are using the same userid and password elsewhere). Doesn't surprise me that it can also be exploited to break SSL/TLS. From that angle I would say that part of the overall issue is after all the way we're using TLS (though the underlying leakiness is how the exploit actually occurs). The problem is, what do you do instead?
Parent
SSH not affected (Score:3, Informative)
Re:Not so sure (Score:3, Interesting)
Okay. I recently suffered a man-in-the-middle attack. I was faced with the choice of using insecure alternatives to communicate, or not being able to read email or update my website.
My family quite often have problems with secure email. It doesn't take a genius to work out that when their secure email fails, they turn it off and write plaintext emails.
MitM attacks are not to be sniffed at. With the clueless [or deadline-pressed] public, you can defeat encryption just by scrambling it.
Not vulnerable to MITM as you describe (Score:5, Informative)
Bull pucky.
SSL is not vulnerable to a MITM during key exchange as you describe iff you are verifying certificates. HTTPS, as implemented in web browsers and other software that includes a list of trusted certificate authorities (CAs) does verify certificates. Not only that, but it requires that the common name (CN) match the host name, to prevent me (I have a cert for ssl.example.com) from interposing myself between a client and your server (www.some_domain.com) with my valid CA-signed ssl.example.com certificate.
Now if you use a client that does not support certificate verification, then yes, you are vulnerable to a MITM. For example when you use SSH and connect to a host for the first time and do not already have a copy of the host key stored on your machine (perhaps you got it on a floppy, loaded it from a web page, or some other method of getting it that you trust) then you must blindly say "Yes, I trust this fingerprint is correct." If you do this, then you may have been MITM'd, and you wouldn't know.
The best bet in this case is to check the actual server certificate once you log in and make sure that it matches the one you just accepted. You'd need to "cd /etc/ssh; cat ssh_host*.pub" and compare the output of the server keys to the one just entered into your ~/.ssh/known_hosts file. True, if you were MITM'd, then the cracker could be re-writing the keys you read from your cat command, but that's a pretty high bar for it to get over. (You might run 'less' or 'more', etc, so it's difficult for it to know when you're viewing the actual server key.)
So, in summation, if your use of SSL (or any public-key crypto) doesn't include certificate verification (or the appropriate analog), you are always vulnerable to a MITM attack. Major HTTPS implementations do not fall into this category.
Parent
So what the man in the middle does (Score:4, Interesting)
Granted, this sort of attack can't be very easy unless he has total control of a router in between you and the server, but unless there's some out of channel way of verifying the private keys (web of trust or certifying authorities, for example) then this is at least theoretically possible.
Parent
Re:So what the man in the middle does (Score:3, Informative)