SSLStrip Now In the Wild 208
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."
Alternatives (Score:4, Interesting)
Re:Not the end of the world (Score:4, Interesting)
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)
"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)
Re:Not the end of the world (Score:3, Interesting)
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.
Re:Not the end of the world (Score:3, Interesting)
Do you know if FF will detect blacklist characters for all TLD's or just the non-IDN TLD's like
An anarchist resource since 2004? (Score:2, Interesting)
Re:Huge pet peeve (Score:3, Interesting)
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)
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)
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)
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!