Re: [TLS] Inter-protocol attacks

[Antoine Delignat-Lavaud <[e-mail]>]

Hi,

Le 8/9/2014 3:58 PM, Watson Ladd a écrit :
> By combining fallback to SSLv3 and session ID based resumption, it is
> possible to do some major damage.

This is an imprecise description. In the case you are referring to, the 
browser fallback behavior is abused to exploit the fact that some 
Mozilla servers had an improperly isolated server-side session cache 
(but, interestingly, it also had well-isolated session tickets, hence 
the need to prevent the victim from using tickets). This is another 
reason why draft-bmoeller-tls-downgrade-scsv should be adopted and 
implemented, as the ability of the attacker to get rid of the SNI and 
session ticket of the client can have bad, unexpected effects on some 
servers.

>   This is due to Antoine
> Delignat-Lavaud according to whois. Slides are at
> https://bh.ht.vc/bh_slides.pdf. This depends on subtleties of TLS
> configuration and interactions with the same origin policy, and
> results in the sort of thing you don't want to see.

Indeed, the attacks I presented rely on improper server configuration, 
plus a very nasty legacy behavior of not rejecting HTTP requests that 
contain an unexpected Host header (I don't anticipate this behavior will 
change). However, TLS is not helping in some regards, and extensions 
that have been described as having no security impact whatsoever 
(including, but not limited to, SNI and session tickets) when in fact, 
there should have been a precise security discussion about the 
application behavior when using these extensions.

> Moral of the story: simplify, simplify, simplify!

What I am seeing is an exactly opposite trend. In particular, I would 
like to attract the attention of the TLS WG on the fact that Chrome 
introduced a very significant change to the authentication model of TLS 
that went virtually unnoticed. In SPDY, the TLS client session cache is 
no longer indexed by domain and port, but instead by domain set, IP and 
port: in classic TLS, an established connection or session can only be 
reused for the same domain, whereas in SPDY, it can be reused for any 
domain in the certificate verified when the session was created, 
provided that it points to the same IP as the original connection. The 
DNS condition is obviously meaningless to a network attacker, which 
means that all security guarantees that were previously session-specific 
should now be considered certificate-specific.

I argued against this behavior with Adam Langley, for several reasons. 
First, it means that our miTLS efforts to prove authentication were once 
again thrown out of the window (not a big deal, but still, such a change 
deserved more than 3 lines in section 9.1.1 of 
draft-ietf-httpbis-http2); second, it explains why current webservers 
are happy to resume connections with an SNI that doesn't match the one 
in the initial connection. Furthermore, they are also accepting requests 
whose Host header doesn't match the SNI of the connection (because 
connection reuse not only occurs at the session level, but also at the 
connection level: if a connection is established with a certificate 
valid for *.x.com, the browser is allowed to send a request first to 
www.x.com, then to static.x.com on the same connection). Unsurprisingly, 
this freedom can be abused by the attacker to exploit an 
improperly-isolated server-side session cache. My third complain was 
that this behavior is not well-known and breaks certain things when one 
is unaware of it. For instance, client authentication and Channel ID 
become hazardous with multi-domain certificates. It may even get worse 
if a malicious domain appears in the certificate, a scenario that sounds 
unlikely but is in fact common in practice (e.g. CloudFlare loves to 
pack unrelated customer domains in their certificates).

It also turns out that this feature has been buggy in Chrome for the 
past 2 years, allowing an attacker universal server impersonation (I 
didn't talk about it at Black Hat because the fix is not yet deployed). 
I'm fairly sure that if there had been more discussion, such an ugly bug 
could have been averted.

For all these reasons, it may be a good idea to reconsider certain 
aspects of the design of TLS in an HTTP context. For instance, it would 
be useful to provide strong implementation requirements about the 
isolation of the session cache, and try to make an explicit decision 
about session-specific vs. certificate-specific security guarantees.

Best,

Antoine Delignat-Lavaud