Swiss Researchers Find A Hole In SSL 234
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
Re:Ugh... (Score:2)
Close, I thought it said SNL. It made perfect sense until I stumbled across the word 'protocol'.
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.
Re:Wait... (Score:2)
Re:Wait... (Score:2)
Not trying to downplay the concept, just interested in the implementation.
Re:Wait... (Score:2, Informative)
Only email is vulnerable because email programs automatically check for new mail at regular intervals. This vulnerability requires that the password be sent frequently to the server. In most other transactions, it's only sent once.
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.
Re:OpenSSL new version has fix already (Score:2)
Re:OpenSSL new version has fix already (Score:2)
Re:OpenSSL new version has fix already (Score:2)
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.
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:2, Informative)
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)
Re:A different kind of SSL? (Score:2)
SSL shouldn't be vulnerable to you sending your password several times within the same session, so it's an SSL vulnerability. The vulnerability does not depend on key length in any way. It takes advantage of some well known security weaknesses in CBC, combied with the server leaking certain information via message timings that it shouldn't be.
The vulnerability merely requires that there be a predictable message in which everything in the password occurs in a predictable location.
But what if I'm a repetitive compulsive buyer? (Score:5, Funny)
Re:But what if I'm a repetitive compulsive buyer? (Score:2, Funny)
Re:But what if I'm a repetitive compulsive buyer? (Score:2)
You will self-destruct without assistance.
Cyber-darwinism at its best.
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.
Re:It's a floor wax. No, it's a dessert topping. (Score:2, Insightful)
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
Re:It's a floor wax. No, it's a dessert topping. (Score:2)
Ok, so Slashdot doesn't pick on just Microsoft.
The protocol allows conforming implementations that allow leakage of information. That the protocol also allows conforming implementations that do not leak the information does not remove the flaw from the protocol.
Re:Compatibility without complete compliance (Score:2, Insightful)
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.
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.
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.
Re:Heise and OpenSSL developers tells the opposite (Score:2, Interesting)
The error messages are encrypted. The attacker can't read them. All his information is based on timing. Because of the implementation a padding error will return faster than a MAC error. After sufficient attempts the attacker can statistically guess which error he's getting. That info can be used to crack the cipher.
I don't know the details of the OpenSSL fix, but they don't have to change the error message to fix the problem. They just have to change the timing. So it's purely an implementation problem; nothing to do with the protocol.
I don't know why Vaudenay said (in the interview) that it was a problem with the protocol because according to the LASEC memo, it's not. Vaudenay didn't write the memo, so it's hard to guess how directly involved he was with the work. The project is based on a method of attacking SSL developed by Vaudenay though. From the memo:
Re:Heise and OpenSSL developers tells the opposite (Score:2)
Although returning the different alert codes isn't specifically what opens you up to vulnerability (because as you noted the alert codes are encrypted), the fact that the RFC has different alert codes for these scenarios leads the implementer down the path of handling them differently (which will easily lead to timing differences if you aren't careful). There is no good reason to have two different error codes for these two conditions in TLS (SSLv3 got it right here and only had a single MAC error code). Two separate error codes leads implementers towards vulnerable implementations.
An analagous attack is the Bleichenbacher attack. The TLS RFC explicitly states what implementers should do to avoid that attack (treat bad PKCS#1 padding just like a bad Finished message). However, instead of having some helpful note about this, the RFC has a very unhelpful suggestion to send a separate alert code for a condition that needs to be treated identically in terms of timing.
No, they didn't know this attack then, but they violated the principle of not revealing more error information than is necessary. They went into detail describing how not to leak to much information about PKCS#1 padding, but then they did not follow their own advice about block cipher padding.
Re:Heise and OpenSSL developers tells the opposite (Score:2)
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...
Re:Huh? We must not have read the same article... (Score:2, Interesting)
Well actually it's any application where interesting plaintext is sent at a known offset in the conversation over and over again.
I think that this means that HTTP Basic Auth over buggy SSL is vulnerable (in other words password protected web pages). Remember that the Auth header is sent in each and every page request, although its absolute offset in each HTTP req will vary with URI length in the GET/POST header. If this is known though...
Re:Huh? We must not have read the same article... (Score:2)
Re:Huh? We must not have read the same article... (Score:2)
It should keep the connection open, and only resend the login details if the server disconnects.
I'm convinced that Microsoft deliberately makes Outlook so bad at IMAP to force people to use Exchange instead....
sorry, too early in the morning, not enough coffee, and suffering flashbacks from battling with Outlook and IMAP (Netscape messenger does it so much better, but everyone insists they 'need' Outlook).
Phew! (Score:3, Funny)
Article was totally off (Score:2, Insightful)
One hour? (Score:2, Informative)
Re:One hour? (Score:2)
Bank / E-Commerce is also vulnerable (possibly) (Score:2, Informative)
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.
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.
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]
Re:flaw is easily avoidable; use RC4 (Score:2, Insightful)
Last year a few friends got together and tested ettercap [sourceforge.net] out (in a controlled environment) and sure enough it's trivial to snoop on a machine's traffic.
Re:flaw is easily avoidable; use RC4 (Score:2)
Seal is patented by IBM (p. 400 of Applied Cryptography) while RC4 is not patented at all (despite its sketchy past as a "trade secret"). Also, there are no SSL ciphersuites defined for SEAL, so you wouldn't interoperate with anyone.
So using SEAL wouldn't actually be useful and it is even more constrained with respect to intellectual property than RC4 is.
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.
Re:flaw is easily avoidable; use RC4 (Score:2)
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.
Re:protocol is slightly flawed (Score:2)
The whole point of the timing attack is to distinguish block errors from MAC errors. If the stack already tells you (through different alert codes) which one of those happened, you don't have to bother with a timing attack. Read RFC 2246 p. 26.
Re:Flaw is in OpenSSL implementation, not protocol (Score:2, Interesting)
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).
Re:Only affects IMAPS? (Score:2)
I stand corrected, the implementation (OpenSSL) is fixed (OpenSSL 0.9.7a). I just hope that sysadmins are better at keeping their OpenSSLs up to date than they are at patching their IIS installations....
Eeek (Score:2, Funny)
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...Re:Eeek (Score:2)
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]
sweet! (Score:2)
And you don't have to be 'sensitive' to get to use it either!
Impact on SSH? (Score:2)
SSH not affected (Score:3, Informative)
Re:SSH not affected (Score:2)
However, is it known for sure that SSH does not suffer from a similar timing-based information leak in its own protocol handling code? I don't know, and I don't know if such an examination has been done (yet).
It is possible that SSH could be exposed to a similar attack if it were used regularly to initiate sessions. For example if you had an entry in crontab to SSH a job onto another machine at regular intervals, you might amass enough sessions to make you vulnerable to this sort of exploit, should one exist in SSH.
Let me be clear, I have no evidence that this is the case in SSH at all, but it seems like a good stimuli to review SSH to ensure it doesn't. Unfortunately, I'm not qualified to do so. Knowing the reputation of the OpenSSH crowd, if has not been done and could be a risk, it will be done.
Many eyes, shallow bugs.
ObMicrosoft: Anyone know if IIS's HTTPS implementation suffers from this weakness?
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.
Realization (Score:2)
Is nothing holey? er, I mean, holy?
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.
Webmail? (Score:2, Interesting)
email... (Score:2, Interesting)
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.
There's a much bigger hole (Score:2, Interesting)
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.
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.
What was that again? (Score:2)
I guess it's been a long week.
OpenSSL bug; NSS not vulnerable (Score:2, Insightful)
This is merely a problem in OpenSSL, and it doesn't affect SSL in general.
Re:Arg!!!! (Score:5, Informative)
Besides which, openssl 0.9.7a was released yesterday, and it addresses these issues.
Re:Arg!!!! (Score:2, Informative)
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
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.
Re:Not so sure (Score:2)
That's probably about right in Windows (cut'n'paste to PGP is an ass, and you can't browse your email folders), but believe me, it becomes a lot easier when you get KMail running.
KMail will just ask you once for the passphrase, and then display encrypted email messages as normal - lovely. The only difficulty is that it can take some time to get GPG itself working, or to import keys. Anyone's welcome to email me to ask for help.
On Windows, the easiest way is to pay $30 for The Bat[ritalabs.com] which includes its own PGP implementation, or Enigmail[projects.mozdev.org] which works with Mozilla mail and GPG. Both of those systems are excellent email clients, with encryption just the icing on the cake.
Don't be tempted to use PGP plugin with Outlook or Express. It has the potential to crash the program, and leave you unable to even see the encrypted text.
This is not a new vulnerability (Score:2, Interesting)
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.
Re:Not so sure (Score:2, Insightful)
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.
I think that is wrong (Score:2)
In the attack being discussed, the MITM is supposed to induce errors, and see how the other end reacts. The certificate doesn't prevent that.
Never underestimate the stupidity of the public... (Score:2)
No, I never assume the public has a brain. Your comments are completely correct. However I was addressing a vulnerability in SSL and HTTPS in particular, rather than a vulnerability of the user sitting in front of their computer.
I've written many times about how blindly clicking "YES" is a great way to defeat your security. SSL is not a magic bullet [hackinglinuxexposed.com], SSH MITM Attack "Challenge" writeup [hackinglinuxexposed.com], and a good section in HLEv2 [hackinglinuxexposed.com] which is unfortunately not availble online. I'm sure you can find a few of my rants in the Stunnel mailing list archives [theaimsgroup.com] as well.
Do I trust that users will possess a brain and use it? Hell no. But that wasn't the original question.
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.
Re:So what the man in the middle does (Score:2, Informative)
Re:So what the man in the middle does (Score:3, Informative)
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:2, Insightful)
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
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?
yes, it does (Score:2)
You should upgrade your OpenSSL version to 0.9.6i or 0.9.7a. If that is not possible, disable all non-RC4 ciphersuites in the mod_ssl config.