Hi, On 22/08/13 00:26, Ryan Sleevi wrote: > 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.
<no hats> I tend to agree. Can see the use case for HSTS. But on the other hand also see that you potentially might want this capability also in non-HSTS environments. Which would suggest an orthogonal approach? Tobias > 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
