Subject: [websec] HSTS extension to defend against TLS protocol rollback?

From: Ivan Ristić <[email-masked]>
Date: Wed, 21 Aug 2013 23:34:35 +0100

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

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 21 Aug 2013 16:26:56 -0700

On Wed, August 21, 2013 3:34 pm, Ivan RistiÄ‡ wrote:
>  _______________________________________________
>  websec mailing list
>  [email-masked]
>  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).

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 22 Aug 2013 02:11:48 +0200

Hi Ivan,

> 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/

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 26 Aug 2013 23:22:20 +0100

Hi,

> as a first step - our hope would be able to use more heuristics to protect

<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

---

From: Ivan Ristić <[email-masked]>
Date: Fri, 30 Aug 2013 10:26:06 +0100

> 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.

> 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

> 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
> 
> 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+)
> 
> 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
> 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