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."
So if i have 60 machines working on it I'll be through in less than a minute??
how many of you actually use webmail? be cool and use good ol' command line mail!!!
It's not a real security flaw -- it's a honey pot.
And I've already been there.
"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.
I'm honored to have been your first target. Thank you.
Shit...that's a good troll!
--thr0d
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
Ha ha ha! Very amusing :)
Speaking of holes... If Iraq enters Turkey from the rear, will Greece help?
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?
"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 think slashdot denies responsibility for this by saying that contributors are responsible for their own spelling.
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.
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.
Then after imploring those present to "kiss the rings", they emphasized that using your credit card was still entirely safe, and sped off in their newly purchased Mercedes-Benz M-Class SUVs.
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.
Anyone else notice that the incorrect word 'flow' was used instead of 'flaw'? Faggots.
The article didn't make that claim, and in fact says:
Apparantly the flow only affects webmail
Looks like it's someone's time of the month...
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!
Sorry, the article was just a bit... short, dramatically so, on the details. The article explains the process involves an attacker interacting with (Sending 'bad' blocks to receive useable info via the errors reported) the server, which would be more possible in an IMAPS tyle use, but less so in most web apps.
/.ed when it didn't load. Sigh. here's wishing for better knowledge of crypto among tech reporters.
I thought the article was already
Returned Peace Corps IT Volunteer
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.
That's what I screamed while cold sweat was dripping down my face.... and then I continued reading and saw that it still is safe to use my credit card. Hmm.... yeah I see how 'hackers' will go for my e-mail password first.
There's probably some good flow coming from that to...
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.
(nt)
What we see depends on mainly what we look for. -- John Lubbock Now search for that bug slave!
Hurray for Gentoo Linux!
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.
You may be right, but I thought the article indicated that this is a crib attack. Because the username and password are sent many times in webmail systems (and because the attacker knows this) a crib sheet can be built up with every transaction. However, the article claims that credit systems and banks only authenticate once, so would not be vulnerable to this attack (I don't know if this is true).
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
This was already discussed at HAL 2001...
Hahah ... that one didn't occur to me until just now :) very funny :)
Stop acting like a baby. If you read the article you would know that its already fixed in the lates version of the affected software.
"The Swiss researchers said they had passed on their findings to SSL's developers, who have closed the loophole in the latest version of the software."
AC said
"My god, it is hard enough to get people to fix things like SQL server or MSDE, "
Oh well, should have used a DB from a vendor who does a better job with patches and security. People are afrad of patching their critical SQL servers because MS sucks ass at patching. They have historically put out patches that either break of mame systems and the result of this is gunshy MS SQL admins.
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.
People often use IMAP over SSL to avoid giving their email password to the whole Internet. Unfortunately, IMAP uses short, repeated messages, which makes it an ideal target for certain cypto attacks.
So, um, is the hole in the protocol or the software that uses the protocol? If it's in the protocol, what software did they fix, what fix did they implement, and how does that make a difference to all the other software that uses SSL?
*) 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.
The protocol should be revised to include specifications on error handling. If an attack of this nature is attempted, the server should at some point stop responding to the bogus packets.
Perhaps you should go into marketing.
Shit...that's a good slogan!
Yeah, because God knows that editors shouldn't edit.
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 traffic is full duplex, don't worry.
So you actually bought into that penis extension spam?
The article neither confirms not denies if this will impact the SSH protocol or its implementations. I expect it probably does not, but I recall last time I compiled SSH I think it required an SSL library. It probably only uses the crypto routines, and not the actual protocol code (which this leakage occurred in), but I wonder if any (Open)SSH experts can comment on this, and if any similar timing information leakage exploits might exist in the SSH protocols.
-- There is no truth. There is only Perception. To Percieve is to Exist.
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
Ok, non-anonymous SSL is immune to M-n-M attacks. Better ?
3.243F6A8885A308D313
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
just an hour ago and it is obsolete already.
Way to piss away your money on computer texts.
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.
Bacon Good For You, Reports Best Scientist Ever
http://www.theonion.com/
ROCHESTER, MN--Bacon, long believed to contribute to heart disease and obesity, possesses significant health benefits, according to a study released Monday by Dr. Albert Gruber, the best scientist ever. "My research has found that three strips of crispy, mouthwatering bacon every morning can actually reduce cholesterol and help slow the aging process," the awesome Gruber said. "What's more, the bacon's positive effects are enhanced when combined with milk shakes and/or marijuana." In 1997, Gruber, a Mayo Clinic cardiologist, was awarded nine Nobel Prizes in Medicine for discovering that frequent oral sex with models cures cancer.
Ron Paul
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.
Just curious since no one has mentioned it?
First cheese, now SSL. Do they have no limits? No qualms? What next? Innocent pastries??? ...Ohmigod... DONUTS. I feel sick.
Is nothing holey? er, I mean, holy?
Returned Peace Corps IT Volunteer
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.
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.
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.
workaround
The problem seems to be when you have a long session with the server, be webmail, imap over ssl or whatever that makes you be in ssl mode for a lot of time. If you are connected in ssl mode to a site where you be for an hour, and at last you buy something with your credit card, you credit card transaction will be vulnerable. Is not related to what travels, but for how long you are connected.
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.
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, SSH MITM Attack "Challenge" writeup, and a good section in HLEv2 which is unfortunately not availble online. I'm sure you can find a few of my rants in the Stunnel mailing list archives as well.
Do I trust that users will possess a brain and use it? Hell no. But that wasn't the original question.
Even if you got off your ass, you wouldn't be implementing mod_ssl, you would be making use of mod_ssl.
Wow, imagine a software error!! Curse those mindless programmers who didnt think of every detail! Honestly, its not a big deal, so people will have to be more careful with SSL... thats sure special... but that happens with what...nearly every program. People are too heavily relying on automation.
It's possible to not follow a protocol exactly without breaking compatibility. Basically all this is doing is returning the same error for two separate error conditions, rather than specifying the specific cause of the error.
This doesn't break compatibility because the cause of the error isn't important to the error recovery logic.
It would be like if there were different '404 not found' error types for no directory and no file errors in the HTTP standard. The protocol could specify returning the specific error, but if the server returned the same error for both, the user wouldn't really care. All they know is that the URL is bad, and they'll have to try another. Unless they're debugging the server they don't really care whether it was a file or a directory.
This SSL thing is similar. It would be important for debugging, but I can't see the user (even if the user is a piece of code) caring where the error was, as long as they know it's a transmission error.
The attack is based on the timming of an error. Simply throw in a random wait timmer on anything suspicious, ie errors and such.
Put your money where your mouth is -
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.
But if I upgrade OpenSSL. would I also have to recompile say ssh, mod_ssl, mozilla etc.?
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
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.
I looked at "A Hole in SSL" and for some reason I could not free myself from reading that as a prOn reference, like the title to some cheap dirty movie.
I guess it's been a long week.
=^..^= all your rodent are belong to us
RAMMS+EIN HATH SPOKEN.
---
Get a gay nick, and 6 months later, the band you got your gay nick from disappears to a hidden homo-hole! THAT IS YOUR WAY.
We all know where any URL on slashdot with the word "goat" in it goes :[ I post this because I almost missed the ACs mentioning it and my karma is higher, so people should see this before they click.
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
The proper way to solve stuff like timing seems to become totally paranoid about timing:
1) Randomize the message-queues: Some requests coming later will be processed sooner than others and vica versa.
2) Randomize the response time or guarantee a response time at a certain time (real-time systems).
3) Maybe even: Compute everything even in case of early failure. Have as few paths of execution as possible handling the request. (Makes it more difficult to intercept and analyse signals from the circuits etc)
4) And of course the system should never ever accept more than N failures, and start blocking out requests based on IP or other "reliable" identification.
Let's never forget there is never 100% security.
http://www.debunkingskeptics.com/
What's really fuckin funny about this is that the mods gave me a -1 and you a +1.... mine for rendundancy even tho it was posted 14 seconds BEFORE the other redundant post... hmmmm. me smells asshole.
I used to be a MS fan but then I was brainwashed. Now I see the Light. Mac OS X pwns u.
What's even more fuckin funny is there are three posts AFTER mine which have at least 2 (some 5) + ratings for being FUNNY?! WTF happened to redundant you cocksuckers?
I used to be a MS fan but then I was brainwashed. Now I see the Light. Mac OS X pwns u.
Good old SSL 3.0 is significantly less vulnerable to this attack than TLS, the IETF proposed standard version of SSL, a.k.a. SSL 3.1.
Although the recent Lasec paper http://lasecwww.epfl.ch/memo_ssl.shtml describes the attack as working on SSL and TLS, the full attack (which reveals an entire password) depends on a property of block cipher padding that is true of TLS but not true for SSL 3.0.
TLS requires that each byte of padding in the last block have the same value, and that the server must check that the values are correct. The attack depends on the attacker's ability to determine if the value of each byte in a block is or is not the proper padding value for the length of padding being attempted by the attacker. This is only possible if the server actually checks the padding byte values. Fot this attack to succeed, it is necessary and sufficient for the server to check the first and last bytes of padding in the block.
But unlike TLS, SSL 3.0 requires only that the last byte of padding have the defined value. All bytes of padding preceeding the last byte have undefined values, and can contain any values at all. Thus it is not possible for an SSL 3.0 server to test the value of any byte of padding other than the last one. SSL 3.0 servers only test the last byte, if they test any at all. Servers that do not test these bytes are not vulnerable.
Consequently, when this attack is applied to IMAPS over SSL 3.0, no byte but the last byte in any cipher block can be revealed. The value of the last byte can only be narrowed down to 1 of N possible values (where N is the number of bytes in the block, 8 for DES, 16 for AES), not to the exact value. That's bad enough that a cryptographer wouldn't ignore it, but it's probably good enough that an SSL 3.0 IMAPS user needn't be too worried about it.
Please try to limit the amount of "this room doesn't have any bazingas"
until you are told that those rooms are "punched out." Once punched out,
we have a right to complain about atrocities, missing bazingas, and such.
-- N. Meyrowitz
- this post brought to you by the Automated Last Post Generator...