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."
"Swiss Researchers Find A Hole In SSL"
Isn't that their style?
Yeah, I know, that joke was cheesey.
What are the actual implications of this hole? "A different kind of SSL" ? Do they just mean a different cypher/key-strength? And if so, it's then fairly technically incorrect to state "it's just webmail" since last I checked, SSL doesn't know or care about the data being transmitted, and isn't going to up and change the protocol features based on if it's webmail or online shopping; any idiot using the broken/weak encryption would be screwed no matter what data is being transmitted.
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?
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.
Those damn army knives have a tool for everything nowadays...
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
Released yesterday: http://www.openssl.org
"But the researchers say the loophole does not apply to credit card transactions, as banks and e-commerce sites use a different type of SSL (Secure Sockets Layer) technology"
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?
Returned Peace Corps IT Volunteer
I don't know, maybe I'm going to buy 160 different items, one at a time, each time sending my credit card number.
Regarding to what the heise newsticker wrote, this fix IS actually in the implementation and was fixed in OpenSSL 0.9.6i and 0.9.7a. So who is right?
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.
Relax. It's a possible attack when plaintext is repeated over multiple sessions and a non-critical error occurs that forces a key renegotiation, not something a script kiddie will run and get a list of every credit card number on amazonl.com.
Besides which, openssl 0.9.7a was released yesterday, and it addresses these issues.
Yeah, but who's got an hour to spare these days...
If at first you don't succeed... How does that go again? Ah, forget it.
The article didn't make that claim, and in fact says:
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.
Thank god I'm using Telnet!
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.
I would note that the one hour figure is for a dictionary attack, implying that the password was, in short, a bad one (not many universities/corporations would even allow a normal word as a password for one of their accounts). If a brute force method is used on a 256 character set, the time required is about 26 times as long (26 times greater complexity). Still a major hole, but more than a day is quite different from an hour.
Commentor says: "Apparantly the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack."
The actual linked article says: "TLS/SSL are used in other secure Internet applications such as e-banking and e-commerce meaning that an attacker could potentially intercept banking transactions, credit card numbers, etc."
Nobody should dismiss a vulnerability just because the exploit was used againest something that "doesnt'" matter. SSL use with IMAP, POP, FTP or any other protocol all relates to each other. Thus a vulnerability in one can lead to more understanding and discovery of more vulnerabilities.
But if you RTFA then you would know that there is a fix already out there for the Linux community at least.
:)
In the case of openssl [9], a new version has already been released (0.9.7a) with a countermeasure against our attack.
And I'm glad I was told about this, now I can go and update my server with the latest version of openssl and recompile stuff that links against it, and I'm now secure against the Swiss
find ~your -name '*base* | xargs chown
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.
Wait, your *both* right.
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
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].
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.
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
SSL is not immune to man in the middle attacks. Where did you get that?!? Any public key system is vulnerable during the first key exchange.
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.
Will I retire or break 10K?
Apparantly the flow only affects webmail...
Oh no ! Now unauthorised crackers are going to be able to read all my spam ! They'll no doubt have the same problem as me trying to find solicited emails in there somewhere...Never, ever lose a file again. Ever.
*) 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 college required students to telnet into their vax machine to retrieve mail up until about 4 years ago, when they trashed everything and went to novell webmail.
I figure this flaw won't affect them till maybe 2015 when they decide that IMAP might be the way to go.
(shrug)
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
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.
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.
The biggest security hole sits between the keyboard and chair.
-Andrew McAllister
This flaw is specific to the SSL protocol. OpenSSH only uses OpenSSL's crypto library, not its SSL stack. (Open)SSH should not be affected.
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
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.
Is receives your public key, and sends his public key to the SSL server in it's place. He also receives the SSL server's public key, and sends his public key to you in it's place. He then decrypts every message you send to the server (which you will have encrypted using his public key, thinking it was the server's public key), reads it, and reencrypts the plaintext using the server's real public key before sending it on to the server.
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.
"This looks like a 'man in the middle' attack to me, not so much a failure of ssl."
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.
I have the feeling the assertions made by the original poster and the researhers are rather different. A few examples:
"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, 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.
Please correct me if I got my facts wrong.
It doesn't matter whether you're using webmail (the article is mistaken in this respect). The issue is if you're doing regular periodic mail checks to a POP or IMAP server where you authenticate over a TLS channel. Because you're constantly sending the same credentials, the SSL/TLS weakness can be exploited and the credentials extracted. This is as true of Pine as of Eudora or a browser that keeps refreshing the inbox page. It's somewhat akin to the way 802.11 WEP's weakness is exploited.
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?
The article in question merely extends previously announced Vaudenay attack against CBC-based symmetric ciphers.
Vaudenay algorithm is a Man-in-the-Middle type of an attack that relies on SSL error messages (invalid_pad and invalid_mac) to effeciently deduce message padding information and (somehow) use it to bruteforce the key.
The attack in current article merely fights the fact that certain SSL/TLS versions do not provide error feedback that is required by the Vaudenay algorithm. So, they measure server response time instead and use it to estimate how much of the message processing the server has performed prior to failing the exchange. This obviously provides a missing information to the Vaudenay algorithm so that it can function as designed.
3.243F6A8885A308D313
The Swiss are all about Holes huh? First Swiss Cheese, Now This!
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.
The one service I can think of that this poses a serious threat to is email (especially POP3, IMAP could be secured by varying the length of the identifier, rendering the position of the password unpredictable), as it's one of the few services that send the password often. Well, it's not like email is in any way confidential; it's usually sent over unencrypted connections anyway. The real danger is in using the same password with multiple services, which opens up all those services once the password is obtained from any one of them.
/. pass is a different story, but that's a different password anyway.
I read all my email over an SSH link to the mail server, using the mail client installed there. This means I send my password over the net about once a week, namely only when I open a new SSH session. My
---
Anyone who believes that corporate research can or should replace university research deserves to live in a world where this has taken place.
Please correct me if I got my facts wrong.
2) Send a junk mail (to everyone - false hits don't matter) advertising a special offer or something to get people keen to click the URL to your spoof login.
3) 99% of punters will a) not look for the 's' on https, and b) not look for the weeny padlock icon.
4) Harvest the passwords, use 'em, and then scarper.
SSL is only secure if a) the user knows how to be sure that it's in use, and b) can trust their own PC.
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.
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.
Sheesh, evil *and* a jerk. -- Jade
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