(Eric Rescorla wrote in response to Ian Grigg)^2: ...
...(4) Active attacks against the client. By this I mean hacking the client, installing a virus, malware, spyware or whathaveyou. (This is now real, folks.) (5) Active attacks against the server. Basically,
Ian, you are right!Of course, SSL/SB doesn't protect against any of these...
Eric, you are right!How? No COMSEC protocol that anybody is seriously considering protects against these attacks. The secure payment protocols that involve signing sort of do, except that they don't protect against all sorts of account-based attacks.
(Ok that was the famous Rabbi joke - hope you all know it - now seriously..)
SSL/TLS are a secure channel, and a pretty good one, but no more. I think Ian's complaint is not really against SSL but against the way it is used in browsers (I suspect he uses SB for Secure Browsing. Ian likes to invent acronyms and he thinks cryptographers should figure them out for themselves. It could be worse, some people send encrypted messages).
...
I thought they were fairly obvious:and you validated that the URL you got was the one you wanted (or at least in the same domain), and you know what's a domain to begin with, and you pay attention to all of that, and the CA is properly validating ownership of domains (do you know how easy it is to be an accepted CA?),
(a) Given that you know Expedia's URL and you type it in, and you
get SSL, and the certificate is from a real CA,
Exactly; as we said, SSL/TLS are good secure channel protocols.then you are indeed protected against all conceivable network-level MITM attacks.
I agree! That's exactly what we try to achieve - using SSL/TLS - in the Trusted Credentials (and logo) Area extension (we implemented for Mozilla). I'll love to hear your comments - see at http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm
(b) If customers were able to actually examine the name of the site they were connecting to, and it was human readable, e.g. "Microsoft Expedia" or a logo or whatever, phishing would be a lot harder.
>.... Yes, it's
I completely agree that the problem is not due to SSL/TLS; in fact our solution is built on the use of SSL/TLS. The problem is with the way it is used in browsers. And in fact almost all phishing/spoofing attacks in fact do exactly what you wrote, i.e., do NOT invoke SSL at all (although really they could have got a certificate e.g. if they were willing to pay a bit). It is just too easy to fool users to not even noticing SSL is not used; even the `big guys` like Microsoft, Chase, Amazon, Yahoo!, e-Bay,... have unprotected web pages where they ask for your password etc. - they may encrypt it when you submit the form, but the user can't know this in advance, and therefore doesn't have any server authentication... (screen shots in paper or for the lazy: http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing_files/image005.gif)disappointing that there's a new attack, but at heart phishing is a con job. It's no more a failing of SSL/TLS that it doesn't protect against it than that it doesn't protect you if you're conned into typing your credit card in the clear.
Eric, I think this was rude, and quite unlike you. Nobody forces you to communicate. An apology would be in place.
That said, I don't have any illusions that I'll convince you and I have no desire to get involved in an endless debate. Accordingly, I'll end my half of the conversation here. Feel free to have the last word.
--
Best regards,
Amir Herzberg
Associate Professor, Computer Science Dept., Bar Ilan University
http://amirherzberg.com (information and lectures in cryptography & security)
begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com version:2.1 end:vcard
