Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×
Security Encryption

Swiss Researchers Find A Hole In SSL 234

in4mation writes "The folks at LASEC have found a flaw in the SSL protocol. 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.' Apparently the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack." Update: 02/20 20:52 GMT by T : Kurt Seifried writes to say that this is almost exactly wrong: "The flaw is in IMPLEMENTATION, NOT THE PROTOCOL. Due to the way error checks are handled an attacker can find out which error condition occurred by measuring the response. The solution is trivial, a path that forces OpenSSL to do the second check even if the first one fails, thus denying the remote attacker any information as to which exact error condition occurred." He includes a link to the security advisory at Update: 02/20 21:49 GMT by T : Read on below for some more information from SSL 3.0 designer Paul Kocher.

Kocher, President & Chief Scientist of Cryptography Research, Inc., writes:

The referenced paper ( 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 ( For more information, also see 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."

This discussion has been archived. No new comments can be posted.

Swiss Researchers Find A Hole In SSL

Comments Filter:
  • Ugh... (Score:5, Funny)

    by Anonvmous Coward ( 589068 ) on Thursday February 20, 2003 @04:17PM (#5346523)
    "Swiss Researchers Find A Hole In SSL"

    Isn't that their style?

    Yeah, I know, that joke was cheesey.
    • Re:Ugh... (Score:3, Funny)

      by Dr Caleb ( 121505 )
      "Swiss Researchers Find A Hole In SSL"

      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)

        by frenetic3 ( 166950 )
        Did anyone else read that as "Swiss Researchers Find A-Hole In SSL" and think, "How did he get there?"
        No. No, man. Shit, no. I believe you get your ass kicked saying something like that. :P

      • "Did anyone else read that as "Swiss Researchers Find A-Hole In SSL" and think, "How did he get there?"

        Close, I thought it said SNL. It made perfect sense until I stumbled across the word 'protocol'.
  • Wait... (Score:3, Interesting)

    by Anonymous Coward on Thursday February 20, 2003 @04:18PM (#5346537)
    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?
    • Re:Wait... (Score:5, Insightful)

      by Oculus Habent ( 562837 ) <> on Thursday February 20, 2003 @04:30PM (#5346651) Journal
      Webmail is insecure because it resends the same data (username & password) regularly to the server. Credit Cards submissions and sign-in pages are unlikely to keep sending the same data repetetively.

      Of course, we just need a better webmail application, and you'll be fine.
      • Well, the authentication/authorization system I have just completed for my web applications sends the password once. A cookie is returned to the user as a Session ID. The Session ID is good only for the very next transaction. Upon completion of the next transaction, the Session ID is rotated to a new value, which again is good for the very next transaction. It's really only a couple of extra lines of code to implement.
        • What happens if someone wants to open a link in a new window, or work on two sections at the same time?

          Not trying to downplay the concept, just interested in the implementation.
    • Re:Wait... (Score:2, Informative)

      by lazira ( 651928 )
      last I checked, SSL doesn't know or care about the data being transmitted

      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)

    by Anonymous Coward on Thursday February 20, 2003 @04:18PM (#5346538)
    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.
  • The Swiss (Score:5, Funny)

    by bytesmythe ( 58644 ) <bytesmythe&gmail,com> on Thursday February 20, 2003 @04:20PM (#5346549)
    Those damn army knives have a tool for everything nowadays...
  • by linuxbaby ( 124641 ) on Thursday February 20, 2003 @04:20PM (#5346554)
    Since not everyone reads the article, don't miss this line from it:

    In the case of openssl [9], a new version has already been released (0.9.7a) with a countermeasure against our attack.

    Released yesterday: []

  • BASIC? (Score:2, Funny)

    by sharph ( 171971 )
    An SSL-enhanced browser such as Internet Explorer or Netscape Navigator uses encryption to scramble the data you send to a web site into an unintelligible string of seemingly random characters. A typical transaction is a browser sending the contents of an order form to the server, checking emails on an IMAP server, using BASIC authentication to access a password protected part of a website, etc. Let's look at an example showing the difference between unsecure and secure transactions:
    Of course its insecure, they programmed their security in basic. (I'm smarter than this. It's a joke... Laugh.)
  • by griffjon ( 14945 ) <> on Thursday February 20, 2003 @04:22PM (#5346572) Homepage Journal
    "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?
    • 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.

      I thought the article was already /.ed when it didn't load. Sigh. here's wishing for better knowledge of crypto among tech reporters.
    • by Anonymous Coward on Thursday February 20, 2003 @04:28PM (#5346630)
      The problem comes from forming the same strings, crypting them and sending them over and over again. Banking sessions, etc, do not send your authentication tokens over SSL many times, they simply send once, and then set a secure cookie.

      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.
      • Actually a cookie such as you describe might well be vulnerable to a leaky-cipher problem like this one, since the HTTP headers are reasonably large, uniformly located (in part because of the punctuated way HTTP is used between browser and server), and generally much the same for subsequent requests. It seems this would probably be worse for, say, RC4 (for the same sorts of reasons as WEP is breakable).

        This is why the cookie is only good for a session and has a short timeout. You may be able to grab some candy, but you can't steal the whole store.
    • Here's the article itself []
    • It sounds like the BBC reporters may have actually talked to the researchers, rather than just repeating what they posted online.

      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)

    • 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.

  • by djeez ( 472062 ) on Thursday February 20, 2003 @04:23PM (#5346579)
    I don't know, maybe I'm going to buy 160 different items, one at a time, each time sending my credit card number.
  • by kju ( 327 ) on Thursday February 20, 2003 @04:23PM (#5346581)
    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.
    • 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.

      • by kju ( 327 ) on Thursday February 20, 2003 @04:37PM (#5346720)
        Ok, but then the slashdot article was some sensation laden journalism. It specificially said that the flaw is in "the SSL protocol itself [...] not [...] how we implement it". So this leads to the impression, that SSL is flawed by principle and could not be fixed without altering the protocol.

        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.
        • Imagine that the fuel pump in your car breaks down. You need to get somewhere and don't have the parts to fix the fuel pump, but you do a good stock of odd stuff lying about. So you take a bottle, some hose, and a coat hanger, fill the bottle with gasoline, run the hose into it and hang the lot from your dome light, allowing gravity to feed fuel to the carb. (Yes, I've actally done this. It's a real world example).

          Or, your boat has a hole in the hull, so you dive overboard, throw some canvas and underwater putty over it, and go on your way.

          Your car and boat are still broken and require repairs of their fundamental structure, but, for the moment, can be considered as functioning normally.

          One can kludge software in a like manner at times.

          This is one of those times.

        • Ok, but then the slashdot article was some sensation laden journalism.
          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.
      • by cicadia ( 231571 )
        The exploit is a timing attack; a side-channel attack against an actual implementation of the protocol, not the protocol itself.

        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.

    • by XenonOfArcticus ( 53312 ) on Thursday February 20, 2003 @04:35PM (#5346703) Homepage
      *) 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.
    • by nestler ( 201193 ) on Thursday February 20, 2003 @04:38PM (#5346746)
      It's a slight bug in the SSL protocol that is entirely fixeable in the implementation.

      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.

      • Not quite.

        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:
        In 2002, Vaudenay [10] presented an attack which enables the decryption of blocks provided that error messages are available (as a side channel attack) and sessions do not abort. This is not the case with TLS/SSL. We can solve the latter problem in the case where a TLS/SSL session includes a/several critical plaintext block which is/are always the same (e.g. a password). The former problem of availability of error messages (encrypted in TLS/SSL) is solved by performing a timing attack i.e. by measuring the taken for error messages to come back from the server. It is then possible to perform the attack over several sessions of TLS/SSL.
        • You are correct that they didn't need to change the alert code to fix the problem. I mispoke due to confusion from reading their code before yesterday's fix. Even before the fix, their code made sure to return the same alert in both cases, but there was still a timing difference because of the MAC computation.

          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.

    • Interestingly, the research notes that the email program tested was set to check all of its accounts every 5 minutes, thus scuppering any security that relies on timestamps. Somewhat offtopic, but certainly an interesting thing to note for people designing systems.
  • Yeah, but who's got an hour to spare these days...
  • banking too (Score:5, Informative)

    by sarice ( 26064 ) on Thursday February 20, 2003 @04:25PM (#5346605)
    "Apparantly the flow only affects webmail and not banking or credit card payments"

    The article didn't make that claim, and in fact 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.
  • by aborchers ( 471342 ) on Thursday February 20, 2003 @04:27PM (#5346609) Homepage Journal

    Apparantly the flow only affects webmail and not banking or credit card payments

    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...

    • 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...

      • Precisely. IMAP is a particularly good example of a target because the same block of text is sent on a predictable interval when the mailer is set to check for mail every n ticks. I can't think off hand of that many password-protected web apps that refresh with the regularity of an IMAP client/server exchange, but you're right in noting that anythng using SSL and repeating an exchange is vulnerable.

  • Phew! (Score:3, Funny)

    by LongJohnStewartMill ( 645597 ) on Thursday February 20, 2003 @04:28PM (#5346622)
    Thank god I'm using Telnet!
  • by TBC ( 11250 )
    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.
  • One hour? (Score:2, Informative)

    by chronus22 ( 645600 )
    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.
    • They didn't say it was a dictionary attack on the password that took only an hour. Furthermore, if the description they gave was correct, their attack should be linear in the length of the password, not exponential. This means that it can be cracked easily in a few hours with brute force anyway.
  • 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.
  • by nestler ( 201193 ) on Thursday February 20, 2003 @04:30PM (#5346652)
    The easiest way to avoid this flaw (which unfortunately few people know because of all of the poorly written hype) is to use RC4. The flaw is only present when using block ciphers, and RC4 is a stream cipher.

    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.

    • by arivanov ( 12034 ) on Thursday February 20, 2003 @04:47PM (#5346854) Homepage
      RC4 has a history of implementation flaws. It is a good algorithm but it is quite often applied to the wrong problem and IMO anything that is not classic stream and has known plaintext fragments is a "wrong problem". The results of such misapplications are well knonw. MSFT 40 bit PPTP, WEP are just a few fine examples.

      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.
      • RC4 has a history of implementation flaws. It is a good algorithm but it is quite often applied to the wrong problem and IMO anything that is not classic stream and has known plaintext fragments is a "wrong problem". The results of such misapplications are well knonw. MSFT 40 bit PPTP, WEP are just a few fine examples.

        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.

      • by fv ( 95460 ) <> on Thursday February 20, 2003 @07:00PM (#5347935) Homepage
        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

        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.

        Concerned about your network security? Try the free Nmap Security Scanner []

        • Indeed eithernet (even switched) is susceptible to a problem where a gratuitous arp is sent (from the bad guy's computer) that causes a machine (victim's computer) to think an IP address (eg the gateway) maps to an incorrect MAC address (the bad guy's NIC).

          Last year a few friends got together and tested ettercap [] out (in a controlled environment) and sure enough it's trivial to snoop on a machine's traffic. :(
    • [NOTE: This post assumes you use a UNIX or UNIX-like system and OpenSSH]

      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:
      Ciphers arcfour
      Protocol 2
      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.
  • by seifried ( 12921 ) on Thursday February 20, 2003 @04:31PM (#5346664) Homepage
    As usual the slashdot editors have gotten it completely wrong. The flaw is NOT in the protocol. It is in the implementation. When checking CBC (Cyclic Block Chaining) packets for errors (i.e. the kind created by a man in the middle attack) two error checks are done. If the first one fails a reply is sent, if the first one passes and the second one fails the same error is sent, but of course it takes a bit longer then if the error had been triggered by the first error check. This allows an attacker to replay data from another users session against the server, creating errors, by knowing which of these errors occured they can mount an adaptive attack and home in on the data. This attack requires an attacker to be able to monitor data between a client and server, as well as establish a connection with the server.

    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.

    • by nestler ( 201193 ) on Thursday February 20, 2003 @04:41PM (#5346789)
      The protocol RFC says that you should send different alert codes on the wire for the two different cases which is what this attack needs to work. So the protocol is flawed in the sense that following the RFC to the T makes you vulnerable.

      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.

    • I hope people take your advice and actually read the OpenSSL Advisory, which does a fairly good job of explaining the problem and the fix. This is an implementation "flaw" only in the sense that the implementation failed to protect against a previously unknown timing attack. OpenSSL is almost certainly not the only implementation to get this wrong. Wonder how long it will be before someone finds this flaw in MS's CryptoAPI libraries?
  • by mbogosian ( 537034 ) <matt@aren a u n l i m> on Thursday February 20, 2003 @04:31PM (#5346670) Homepage
    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).
    • At least, that is, until the protocol is fixed (if that's possible).

      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)

    by IanBevan ( 213109 )

    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...
    • Heh. If only it were the limit, then it'd be a nonissue. But what if the password on your webmail account allows the attacker to get shell access to that machine, and then exploit some local root hole? It's conceivable.
  • From bugtraq (Score:5, Informative)

    by WPIDalamar ( 122110 ) on Thursday February 20, 2003 @04:41PM (#5346786) Homepage
    For more info... from bugraq:

    "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: []
  • Swiss Researchers Find A Hole In SSL

    And you don't have to be 'sensitive' to get to use it either!
  • 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.
    • SSH not affected (Score:3, Informative)

      by nestler ( 201193 )
      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.
      • Thanks for clarifying that SSH only incorporates the crypto code from SSL, and does not use the affected protocol handling code.

        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)

    by korny69 ( 132030 ) on Thursday February 20, 2003 @04:45PM (#5346825) Homepage
    The attack deals with reoccuring data being sent between the client, man-in-the-middle, and the server. This deals with any data being sent many times across an SSL session and not just passwords, although passwords coming from a mail client such as Evolution, Outlook, Outlook Express, or whatever is a good example.

    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.

  • 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?
  • by RAMMS+EIN ( 578166 ) on Thursday February 20, 2003 @04:56PM (#5346938) Homepage Journal
    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.

  • by ksplatter ( 573000 ) on Thursday February 20, 2003 @05:06PM (#5347047)
    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.
  • Webmail? (Score:2, Interesting)

    by gmuslera ( 3436 )
    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.
  • email... (Score:2, Interesting)

    by RAMMS+EIN ( 578166 )
    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.

    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 /. pass is a different story, but that's a different password anyway.

    Anyone who believes that corporate research can or should replace university research deserves to live in a world where this has taken place.
  • 1) Create a spoof website that impersonates a login page of a eCommerce/eBank site of your choice.

    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)

    by Black Parrot ( 19622 ) on Thursday February 20, 2003 @06:20PM (#5347638)

    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.

  • 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.
  • 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.

A debugged program is one for which you have not yet found the conditions that make it fail. -- Jerry Ogdin