On 22/08/2013 01:11, Yngve N. Pettersen wrote: > Hi Ivan, Hi Yngve,
Thank you for providing so much material. (Yngve also emailed me directly with further information.) It took me some time to go through all of it. > On Thu, 22 Aug 2013 00:34:35 +0200, Ivan Ristić <[email protected]> > 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 > > This have been discussed a couple of times in the TLS WG group the past > couple of years, and was discussed at the TLS WG's IETF 84 meeting in > Vancouver <http://www.ietf.org/proceedings/84/tls.html> a year ago. For those interested, here are some useful links: http://my.opera.com/yngve/blog/2012/11/02/standards-work-update https://www.ietf.org/mail-archive/web/tls/current/msg08099.html http://www.ietf.org/mail-archive/web/tls/current/msg08861.html > In those discussions there were two groups of proposals: > > 1) A couple of variations from EKR and Adam Langley using Special Cipher > Suite signaling (SCSV) to indicate the client's maximum supported > version so that the server could know the client was being downgraded > for some reason, and > > 2) my proposal to use the server's ability to respond with the RFC 5746 > Renego extension as a proxy indication that the server is (or ought to > be) able to tolerate a client signaling a newer TLS version than > supported by the server, and force a new handshake signaling the highest > supported version if a fallback is occurring. This approach is deployed > in Opera versions 10.50 to 11.0x and 12.x (not v15+) > > As the discussion is being reopened, I have just refreshed my draft > <http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/> > . I have not updated the statistics, since I do not yet have recent > statistics that can be used. > > Regarding your proposal I think it may rely too heavily on the server > administrator actively enabling this extension. While the extension > could be added automatically, it might depend on the server either being > the TLS server too, or automatically aware of the front-end's version, > or the front-end will have to add the extension while it is forwarding > the HTTP response (and in that case there might be additional issues > related to variations of HTTP, such as SPDY). > > Additionally, I think a longterm problem would be how to determine when > to finally disable the client support for rollbacks? I think the goal > should be to remove version rollback as a client option. > > Regarding your short description of how it would work, I'll also note > that the client would not be able to see the HSTS header before it have > actually sent a HTTP request to the server (IOW, similar to the > pre-existing HSTS bootstrap problem), and in the case of a rollback > attack that will be *after* the attacker have managed to force the > client to roll back to an older version. This would then mean that the > attacker is (supposedly) able to decrypt (or otherwise compromise) the > information sent in that request (cookies, login credentials, credit > card info, etc.). Once the client have received the HSTS header it will > then have to close the connection, reconnect and negotiate using its > highest version without allowing rollbacks, and perhaps resubmit the > request (which have various problems concerning requests that have side > effects, e.g. purchase actions). > > This approach would probably work against attackers that are using > attacks of the kind used in BEAST or CRIME if newer protocol versions > have been patched against the particular attack being deployed. > > I am also not sure if it is such a good idea to migrate detailed > transport layer information (version support) into a higher level > protocol (HTTP). I think this one is tricky. Browsers could fix the problem quickly, by dropping voluntary rollback, because it's not specified by the protocol anyway. But they clearly don't want (yet) to do it, because of the potential interoperability problems. Personally, I share your views that this should be addressed in the TLS protocol, initially by adopting your proposal, but also later by adding an explicit mechanism to communicate highest supported protocol versions, by both the server and the client. But even with your proposal there will be false positives, and the key question is whether the browsers want to go there. Going the HSTS route side-steps the problem with the false positives, and enables those who care about their security to close a substantial hole in their armour. For such people, there is no significant additional burden, because HSTS is basically mandatory for robust security. (As a side note, perhaps specifying the highest supporting version in HSTS is not necessary. Disabling rollback might be sufficient.) Sure, it's a band-aid, but that's what HSTS is. -- Ivan _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
