Alaric Dailey wrote: > Boris Zbarsky wrote: >> Alaric Dailey wrote: >>> Sure even if we don't steal the cert, most users don't read error >>> boxes so you could redirect them and use a fake cert.
That's an application program UI design flaw, and is not in any way a flaw in SSL. SSL detects the error and reports it. It has done its job at that point. If the application and/or user ignores that, the results do not reflect badly on SSL. >> This is again an orthogonal problem. Browser handling of things like >> hostname/cert mismatches is abysmal. If they don't match, we should >> not show the site, period. In my opinion, of course. > I would tend to agree along with a few other things. We all agree on that! But many vocal users do not. :-( >>>> Actually, even if you have the right IP you _still_ might be in the >>>> wrong place thanks to virtual hosting. And again, SSL will detect that. As of FF 2, FF's SSL/TLS code now has the ability to send the desired host name to the server during the handshake, so that if the server serves multiple virtual hosts, it can pick the cert for the right one and answer with it. >>> exactly! and one more place for an attack. Lots of places for attacks. Thankfully, SSL detects them. >> But again, if the cert presented doesn't match the hostname the >> browser requested the browser should not show the result. > However, with a DNS attack in combination (drive by pharming, dns > hijacking, hostfile modification with malware etc... ), the browser > becomes helpless to detect the problem. No, wrong. Regardless of how many attacks are done, falsifying IP addresses, port reassignment, false routing, and direct MITM data rewriting, unless the final host has a cert from a trusted issuer, and that cert has the host name that was in the user's URL, the attack is detected and thereby thwarted. Period. > In any case, if the user clicks thru the warning box, Then the user has chosen to hurt himself. Not SSL's fault. The user's willingness to hurt himself is a vulnerability of the user, not of SSL. > or if the DNS is hijacked so the browser can't tell, With SSL, the browser can always tell. What the browser does after being told about the detected error/attack does not reflect on SSL. > the assertion of the identity in the certificate is meaningless. If ignored by the user or his application, all security provisions are meaningless. > This has been my statement about how DNS can sabotage identity > assertions all along. So far, the only vulnerability you've identified is in the user, and arguably in the application's UI design, but not in SSL. Your repeated assertions that SSL is vulnerable to falsified DNS simply don't hold up. I'm sure you will continue to repeat it, but you won't convince the readers here. > But then again this DNS issue was only one specific example of a > particular problem with SSL, one of many that EV certs do NOT address. I guess you will repeat this in the face of evidence to the contrary. Go ahead, but you're not making any points. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
