If you're connecting to a website that looks the same, but the URL is slightly different, it won't help. What's more, the URL doesn't have to be different for the entire user's session.
Could you explain further what sort of MITM attack you mean for which SSL doesn't help? (Are you assuming users who don't insist on an SSL connection with a recognized domain?)
The certificate needs to match the domain and bear a signature chain that traces back to your root certificate store. SSL was designed to assume that the DNS is totally insecure, which of course it always has been.
The problem with Man in The Middle attack is that it's a fundamental problem. It's on the same level as the Two Generals problem. In a way it's a variation of it. The only way to deal with it is to have a 2nd channel. Everyone who has to deal with security would be well advised to actually study this, and not blithely wave it away:
This isn't true at all. Mutual key agreement between two unrelated parties talking for the first time is hard problem. SSL gets rid of that problem by having every participant in the system rendezvous with 10+ CA's before they talk to anyone.
The SSL problem is mutual key agreement between two related parties communicating for the first time, and it's an easy one to solve.
There is a really persistant meme that SSL breaks when the DNS breaks, because all that happens when your certificate doesn't match or verify is that you get a warning. That warning says SSL isn't working anymore. You're not supposed to click through it. Real applications that use SSL under the hood don't pop up warnings: they freak out and quit.
"There is a really persistant meme that SSL breaks when the DNS breaks, because all that happens when your certificate doesn't match or verify is that you get a warning. That warning says SSL isn't working anymore. You're not supposed to click through it."
I didn't know it was this bad, Browsers should "freak out" and totally refuse to proceed with the page then.
The problem with this is that SSL certificates can become nonverifiable through innocuous circumstances --- for instance, by expiring, or by moving. Most providers and most users would not accept a hard failure in this case.
And there you have one of the biggest problems with DNSSEC --- without a massive software revamp, there's no "soft" failure mode. gethostbyname() doesn't have a warning channel.
OK, you agree SSL does protect savvy users from MITM attacks.
You're talking about users who can be tricked into what are essentially non-SSL or degraded SSL (certificates from untrustworthy authorities) sessions, because they misread the URL bar or ignore warnings. That's a legitimate concern, most users are easily tricked, but that's not a vulnerability of SSL itself.
That may or may not be true, but what is certain is that additional mucking around with salts, Javascript crypto, and protocols isn't going to improve the story you get with HTTPS.
Comments
You can't rely entirely on SSL. You're still vulnerable to man in the middle attacks, among other things.
No, the whole point of SSL is that it is not vulnerable to MITM attacks, because the client carries anchor keys.
If you're connecting to a website that looks the same, but the URL is slightly different, it won't help. What's more, the URL doesn't have to be different for the entire user's session.
If you want to call that a "man in the middle attack", I won't argue, but as far as I'm concerned, that's a UI problem.
Could you explain further what sort of MITM attack you mean for which SSL doesn't help? (Are you assuming users who don't insist on an SSL connection with a recognized domain?)
DNS poisoning enables a MITM attack even if you're connecting to your safe, legitimate domain.
The certificate needs to match the domain and bear a signature chain that traces back to your root certificate store. SSL was designed to assume that the DNS is totally insecure, which of course it always has been.
SSL throws all sorts of warnings if the cert doesn't match the domain.
The problem with Man in The Middle attack is that it's a fundamental problem. It's on the same level as the Two Generals problem. In a way it's a variation of it. The only way to deal with it is to have a 2nd channel. Everyone who has to deal with security would be well advised to actually study this, and not blithely wave it away:
http://www.webmasterworld.com/website_technology/3711575.htm
Read the whole thread and learn. SSL can only protect savvy users. Depending on how sensitive your data is, this can still be a problem.
Combining this with DNS poisoning would be particularly bad.
This isn't true at all. Mutual key agreement between two unrelated parties talking for the first time is hard problem. SSL gets rid of that problem by having every participant in the system rendezvous with 10+ CA's before they talk to anyone.
The SSL problem is mutual key agreement between two related parties communicating for the first time, and it's an easy one to solve.
There is a really persistant meme that SSL breaks when the DNS breaks, because all that happens when your certificate doesn't match or verify is that you get a warning. That warning says SSL isn't working anymore. You're not supposed to click through it. Real applications that use SSL under the hood don't pop up warnings: they freak out and quit.
"There is a really persistant meme that SSL breaks when the DNS breaks, because all that happens when your certificate doesn't match or verify is that you get a warning. That warning says SSL isn't working anymore. You're not supposed to click through it."
I didn't know it was this bad, Browsers should "freak out" and totally refuse to proceed with the page then.
The problem with this is that SSL certificates can become nonverifiable through innocuous circumstances --- for instance, by expiring, or by moving. Most providers and most users would not accept a hard failure in this case.
And there you have one of the biggest problems with DNSSEC --- without a massive software revamp, there's no "soft" failure mode. gethostbyname() doesn't have a warning channel.
OK, you agree SSL does protect savvy users from MITM attacks.
You're talking about users who can be tricked into what are essentially non-SSL or degraded SSL (certificates from untrustworthy authorities) sessions, because they misread the URL bar or ignore warnings. That's a legitimate concern, most users are easily tricked, but that's not a vulnerability of SSL itself.
My assertion is that you can't just use SSL and leave it at that. In that case, you're only going to protect savvy users, and not even all of those.
That may or may not be true, but what is certain is that additional mucking around with salts, Javascript crypto, and protocols isn't going to improve the story you get with HTTPS.