On Tuesday, 13 August 2013 14:59:15 UTC+3, Gervase Markham wrote: > On 13/08/13 08:44, Mikko Rantalainen wrote: > > > I cannot speak for Ian, but I'd guess "neutral" mode means something > > along the lines "use encrypted connection but do not show any > > additional 'secure' UI decorations". That would be suitable for cases > > http://www.gerv.net/security/self-signed-certs/ deals with some of the > arguments usually raised in this regard. > [...] > > Say you have an HTTPS bookmark to your bank. You visit it (your techie > friend told you "always use this bookmark for your bank, and you'll be > safe"), and someone MITMs you using "neutral mode". Instead of the big > warning you get now, you'd have to notice the sudden lack of secure > indicators. Ideally, you would, but it's a much less obvious failure > mode than the current warnings.
I would not claim that such bookmark would be always safe. I'd say that such a bookmark would be highly probably safe, if that bookmark did include fingerprint for the site public key (*not CA key fingerprint*) and the browser did verify the fingerprint before entering the site. The truth is, even most informed users will visit their bank by entering "bank.com" instead of "https://bank.com"; and as a result, MitM attack is possible unless the bank uses HSTS header AND browser supports it AND user has previously visited the site without MitM attack. Even in best case (as long as the key fingerprint is not verified), an attacker with deep enough pockets could purchase his own CA (e.g. http://www.quovadisglobal.bm/CertificateServices/RootServices/RootSigning.aspx) and create a certificate for his fake site for MitM attack. The only deterrant is that *when* such attack is noticed, the purchased CA key is revoked and the money spent on it will be lost. If the attacker can steal enough money (or e.g. valueable information), it will still be worth the attack. The *only* way to really avoid this is that banks would provide their secure site public key fingerprint and ask their users to verify the fingerprint before entering any secret on the site. The bank could provide this key e.g. on paper when the user visits the bank in person. In the real world, no bank does this. Implementing MitM attacks that intercept traffic for lots of users is hard enough to not happen commonly. It's much much easier to attack the user's computer and steal the secrets directly from the system. If I were to decide, I'd use identical indicators for normal certs and self signed certs and only display difference between those if user clicked the indicator (usually the "lock" icon). This is because the cheapest CAs do so bad work that the security is very close to self signed cert. Additional indicators were displayed only for EV certs in case *all* content came from the site signed in the cert. That is, I'd lose the EV cert green color in case the EV site embedded content from another CA signed HTTPS server. And even with such a strict requirements, the attacker could still purchase his own CA to display valid indicators. In the end, I'd *much* rather take indicator that says that the connection is encrypted but *never* claim that the site is safe. This is because it's pretty easy to tell if the connection is encrypted but it's probably impossible to automatically tell if there's anything wrong (e.g. XSS attack, MitM attack, trojan or virus running in local system, backdoor in the remove system). _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
