First off, this is really not something that should be considered acceptable for banks.
The objective here is purely to increase the amount of SSL traffic on the web so that unencrypted traffic becomes the exception rather than the rule. On Thu, Sep 22, 2011 at 4:39 AM, Gervase Markham <[email protected]> wrote: > On 21/09/11 14:18, Phillip Hallam-Baker wrote: > > Promiscuous security: > > The site deploys SSL as an option that browsers can choose to use. > > Pages may include transcluded content from insecure sites. The cert may > > just be a self signed cert, browsers should just silently upgrade the > > transport to TLS and not bother the user. > > The trouble with this idea (in general) is the following scenario: > > - User has relationship with MyBank.com, and a bookmark to > http://www.mybank.com/. > > - MyBank is not entirely dumb, and so redirects straight to SSL when > requests come in over unsecured HTTP. > Hang on here. What I said was that I wanted this to be part of the pinning mechanism and have persistence. The idea here is to get rid of that browser redirect so that the browser always goes to https. So what would be stored by the browser is: Bookmark: http://www.mybank.com www.mybank.com Always use TLS, Don't enforce strictness, pin=xx, unpin=yy, until=2012-01-12 > - Attacker gains control of user's connection. > > - User uses bookmark to access bank (supposedly a 'best practice') > > - Attacker redirects HTTP request to own MITM server, with self-signed > cert. Browser "silently upgrades transport to TLS, and doesn't bother > the user." Attacker passes through data from real site. > OK so if you use a mechanism that gives secure after first contact you are not going to be secure on first contact. I don't see how this attack is sustained unless you can also sustain the MITM attack. The user should be looking at their browser and wondering why there is no padlock or any security indicator in any case. As far as they would be concerned the silent upgrade looks no different from going to the sit en-clair. - Effect is: user's browser shows connection as secure, but is MITMed. > Nope, no display of any security chrome whatsoever. I don't want security chrome for DV certs. Why would I want it for self signed certs? The only chrome notification should be for certs that establish accountability. This is why silent acceptance of self-signed certs is not a good thing. > If the user can see the acceptance then its not silent. By silent I mean, do not say anything at all, not do not annoy the user with some braindamaged notification. > We cannot rely on the user's browser always remembering the previous > cert used, or the CA via something like pinning, because for privacy > reasons any pin cache needs to be cleared if the user clears their history. Which is why I am going to want to push out the exact same information via the DNS once there is DNSSEC to back it up. Just take the HTTP header and stick it into a DNS RR record we define. > > Thus I think that either pinning should have a new header (they are > > cheap, IANA does not bite) > > But the list of required headers get bigger and bigger. As Brendan Eich > says, "it's not the last cookie that makes you fat". > Security policy is an important use case. At this point we can kill the cache control stuff as nobody is going to be able to use it once everyone is using TLS :-) I would much prefer to have one security policy header and for strict to be a special case rather than have two. -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
