Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Security The Internet

SSLStrip Now In the Wild 208

Posted by CmdrTaco
from the not-the-marisa-tomei-kind dept.
An anonymous reader writes "Moxie Marlinspike, who last week presented his controversial SSL stripping attacks at Black Hat Federal, appears to have released his much-anticipated demonstration tool for performing MITM attacks against would-be SSL connections. This vulnerability has been met with everything from calls for more widespread EV certificate deployment to an even more fervent push for DNSSEC."
This discussion has been archived. No new comments can be posted.

SSLStrip Now In the Wild

Comments Filter:
  • Alternatives (Score:4, Interesting)

    by jetsci (1470207) on Monday February 23, 2009 @10:53AM (#26957343) Homepage Journal
    I guess the question then is, what do we use as an alternative? What can we even do?
  • by IBBoard (1128019) on Monday February 23, 2009 @11:18AM (#26957591) Homepage

    If you read some of the articles (Forbes and a linked one) he can spoof the appearance of a valid certificate as well using International Domain Names. The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ [a] load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/ [paypal.com]

    For the basic attack then actually checking for HTTPS and a proper validation (not just a padlock, but a padlock and the other markers), but for the fuller attack that takes advantage of the IDN then you'd probably need to read the certificate itself, which would require you to know which certificate you're expecting, which would require something like a page with the signature on saying "look for this", which could then also be spoofed (in cases where it was worth it, e.g. a bank).

  • EV certificates (Score:2, Interesting)

    by Lieutenant_Dan (583843) on Monday February 23, 2009 @11:19AM (#26957601) Homepage Journal

    "for more widespread EV certificate deployment"

    That's probably being sold by Thawte. And considering that a lot of browsers out there still don't support EV.

    Extended validation? When I pay for a digital cert, I expect a high level of validation anyways. Makes you wonder, what level of validation they've been doing for the past few years.

    SSL always MITM as one of its exploits. There's a lot of network gear (e.g. Cisco's IronPort) that do just that in order to enforce security policies of an organization.

  • Hype (Score:2, Interesting)

    by TheRealJobe (1125771) on Monday February 23, 2009 @11:21AM (#26957631)
    Please don't get me wrong, this will make a nice addition to a toolbox. However, the hype I have seen tied to this tool is overwhelming. It seems like conferences have become more reliant on over-hyping items like these to promote the conference name more than anything else.
  • by QuoteMstr (55051) <dan.colascione@gmail.com> on Monday February 23, 2009 @11:31AM (#26957739)

    The certificate won't be valid for the site that you wanted, but that won't matter because it'll have redirected you to https://a/ [a] load of characters that look like 'paypal.com/somepath' but are actually non-ASCII characters].evil.com with a wildcard certificate for *.evil.com and look like https://paypal.com/some-path-here-that-is-really-really-really-really-long.evil.com/ [paypal.com]

    Hrm. I must have missed that; it's a clever trick. Then again, I've always thought international domain names were gratuitously unnecessary.

    The solution to this problem is simple, and I'm surprised browsers don't do this already: add fake '/' character isn't in the IDN blacklist. In Firefox, network.IDN.blacklist_chars already contains plenty of things that look like '/'. Maybe other browsers need to follow its example.

  • by hal9000(jr) (316943) on Monday February 23, 2009 @11:43AM (#26957865)
    The solution to this problem is simple, and I'm surprised browsers don't do this already: add fake '/' character isn't in the IDN blacklist. In Firefox, network.IDN.blacklist_chars already contains plenty of things that look like '/'. Maybe other browsers need to follow its example.

    Do you know if FF will detect blacklist characters for all TLD's or just the non-IDN TLD's like .com and .net?
  • by edgewedge (1481513) on Monday February 23, 2009 @12:28PM (#26958363)
    Holy crap, looking at the source to sslstrip, this was written in 2004! I wonder if the anarchist underground hacking scene has had access to this for all that time? Why release it now I wonder?
  • Re:Huge pet peeve (Score:3, Interesting)

    by QuoteMstr (55051) <dan.colascione@gmail.com> on Monday February 23, 2009 @12:49PM (#26958627)

    Of course users won't actually read the warning. The point is to annoy users so that webmasters eliminate the behavior causing the annoying warning.

  • Re:Alternatives (Score:3, Interesting)

    by Dekortage (697532) on Monday February 23, 2009 @02:01PM (#26959553) Homepage

    Really, you should already be wary when a site asks you for login information over HTTP rather than HTTPS.

    Maybe. The login form might be located on an HTTP page, but as long as the form submits to an HTTPS page, your login credentials are still SSL-encrypted. Conversely, if you have an HTTPS login form, but the form action goes to an HTTP site, your credentials are NOT encrypted.

  • Re:Huge pet peeve (Score:1, Interesting)

    by Anonymous Coward on Monday February 23, 2009 @08:18PM (#26964023)

    It turns out cyrus imap and several other implementations can't do ephemeral session keys in a thread-safe way, apparently because of some awkwardnesses interfacing with openssl 0.9.7l (and earlier). Apache manages it, however, so I think that this is overstated.

    "DH:HIGH:MEDIUM" is a reasonable default ciphers list for openssl.

    Apache enables all sorts of very weak encryptions, and I'm willing to bet that there are many many many sites that don't change the SSLCipherSuite to something safer. A good MITM vector is the SSL ciphers negotiation, trying to force down the amount of encryption the two communicating parties use. Some of the ciphers in EXP can be broken in real time by a well-funded attacker.

    SSLCipherSuite makes a depressing google search term... lots of hits showing how to *water down* the default mod_ssl security (which is insufficiently strong to start with), lots of hits showing how to strengthen it by enumerating a small list of specific ciphers (AES-128-SHA:...) that excludes ciphers with ephemeral session keys. The latter *may* sometimes be weaker ciphertexts on their own, but stronger ciphertexts which can be recorded and attacked in the future if the master private key is acquires are weaker than those that will have to be brute forced ("perfect forward secrecy", PFS) because the particular session key was decoupled from the master private key.

    PFS is simply not a big goal in people's minds, even as the computational burden falls.

    Given that *every* google node that terminates SSL connections *must* have a copy of the master private key (in order for PK to work at all), and there must be windows for an attacker to recover a cleartext copy of that key in reasonable time (everything from social engineering to gaining access and probing physical memory), it is almost certainly easier (and it's clearly more attractive) to attack *all* the sessions protected by the master private key than to attack *most* of the individual sessions.

    Physical access plus a cryogenic gas and insulating box -> you have all the sessions protected under the key if you can recover it.

    Ex-employee -> you have all the sessions protected under the key she or he takes out the door, or the password she or he takes out the door and the encrypted master private key you already have by other means.

    Master private keys that are obsoleted fairly frequently (annually) are no protection, they just close off some of the avenues of recovering the plaintext master private key.

    For my sins, I decided I had to have a *plaintext* copy of my master private key *on disk* on a server because a critical service had no secure way of decrypting the encrypted version. It's protected by ACLs/permissions alone, and a clued-in attacker who gained priviliged access to the server would be able to find it relatively quickly.

    However, that particular service is also doing ephemeral session keys, so recovering the plaintext master private key just opens a spoofing attack (attacker can pretend to be my server), but does not at present make it easier to recover recorded sessions that were protected by ephemeral keys. (Some clients did not do ephemeral session keys, though...)

    PFS = useful.

    PFS is certainly more expensive than no PFS; DH negotiation is costly for CPU and also costs possibly 2xRTT on the network.
    This *was* considered hugely expensive.

    Now, the impact of PFS on user experience is shorter than the authentication wait on password authentication.

    PFS is probably good practice.

    There's an obvious tradeoff between obsessing over PFS and deciding it's not worth it. For instance, there are lots of ex-employee attacks which are at least as attractive (walk away with the backups of all the side-effects left server-side by clients who use PFS or crypto or plaintext...).

    However, given how easy it is to intercept and record traffic for long periods of time without being caught, and how cheap it is to store traffic until it becomes computat

  • Re:Alternatives (Score:3, Interesting)

    by kybred (795293) on Monday February 23, 2009 @11:53PM (#26965507)

    Your first login attempt may fail as the password is redirected to the attacker, but once your attacker has your password, he can return things to normal so your second login attempt will succeed. You'll just think you mistyped the password on the first try.

    That's why I always type my password in wrong on purpose the first time!

"Take that, you hostile sons-of-bitches!" -- James Coburn, in the finale of _The_President's_Analyst_

Working...