Hi Ivan,
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.
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).
--
Sincerely,
Yngve N. Pettersen
Using Opera's mail client: http://www.opera.com/mail/
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
