On 22/09/11 15:42, Paul Hoffman wrote:
On Sep 22, 2011, at 1:39 AM, Gervase Markham 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.
- 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.
- Effect is: user's browser shows connection as secure, but is MITMed.
The "Attacker gains control of user's connection" step isn't necessary if the
attacker is already an MITM, such as an TLS proxy like the one that has been in the news
lately (or the attacker gains admin access on a corporate TLS proxy).
This is why silent acceptance of self-signed certs is not a good thing.
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.
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".
Not sure what you mean by "required". The new one Phill proposed here would be
required to support this functionality, not required for every browser. I agree with him:
granularity for semantics of each header is better than overloading semantics to save a
few bytes.
Also agree with new header. It is not the header field itself that may
get you "fat", it is complexity of parsing if you try to mingle too much
into one. And in fact it is smoother on the end-points to parse one more
defined header fields, than to start more complex parsing and untangling.
Kind regards, Tobias
--Paul Hoffman
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
