On Wed, August 21, 2013 3:34 pm, Ivan RistiÄ wrote: > Pretty soon we're going to see a good chunk of the browsers support TLS > 1.2, and that's great. At the same time, all browsers are vulnerable to > protocol downgrade attacks, whereby an active MITM can downgrade the > connection to SSL 3. > > Given that this is not a TLS issue (it already defends against protocol > rollback), I feel that HSTS would be a good place to implement a > defence. If we have an extension that specifies the maximum TLS version > supported by the server, browsers can refuse to downgrade. (If the > server chooses to negotiate a lower version on the first connection > attempt, well, I guess that that could be acceptable.) > > Has this been discussed here before? > > P.S. In researching this topic I also came across Brian Smith having the > same idea: https://bugzilla.mozilla.org/show_bug.cgi?id=450280#c21 > > -- > Ivan > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec >
We've been experimenting with it in Chromium, though through the list of preloads, rather than as an HSTS directive. Perhaps unsurprisingly, it's turned out rather hard to actually get right when we turned it on for Google.com. See http://crrev.com/195335 and http://crrev.com/199185 I'm not opposed to adding it as a directive to HSTS, but I think that'd be as a first step - our hope would be able to use more heuristics to protect even non-HSTS sites. Yngve had previously proposed a variety of checks for that in the past that we've definitely thought are reasonable. It would be great to be able to deploy. I'd like to slowly see us on the browser side begin to move to a whitelist for SSL3 fallback, rather than the current policies. If browser's bear that inertia cost and evangelism problem, is it still as significant an issue for HSTS (as opposed to having non-browser applications simply disabling/removing fallback, because the browsers no longer do it). _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
