Re: [TLS] Inter-protocol attacks

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

Le 8/11/2014 7:06 AM, Martin Thomson a écrit :
> On 10 August 2014 06:20, Antoine Delignat-Lavaud
> <[e-mail]> wrote:
>> 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.
> The behaviour you describe isn't quite correct, because - I believe -
> that it requires that the DNS resolve to the same IP (or that one of a
> set of alternative values point there).  But that's not a particularly
> important detail, DNS has never been a part of the security story for
> https.  It's a big part of http, but we all know what you get there.

Ultimately, we agree that the precise DNS condition doesn't matter. In 
HTTPS, DNS is under attacker control.

> Either way, this behaviour has been discussed at some length and was
> not found lacking in the SPDY/HTTP2 context.  Yes, HTTP/2 standardizes
> this practice.  The poor handling of Host header fields in HTTP/1.1
> means that it will probably never be advisable to do something like
> this there.
>
> As always, I caution that we have to be careful to distinguish between
> attacks on implementations and attacks on standards.  I am aware that
> there are bugs in implementations.  I'm also told that they are
> somewhat difficult to exploit.

The argument is not whether such attacks are to blame on implementation 
or specification. The question is whether behavior such as reusing a 
connection established with attacker.com to send data meant for 
google.com /should be considered an attack at all/.

This is the TLS mailing list, and the relevant problem here is the 
complete lack of any restriction in RFC 5246 and 5077 on when a session 
can be resumed. Thus, we end up in a situation where resumption is up to 
implementations to decide; because of the lack of any specification, TLS 
libraries simply hand off the decision to the application; the 
application won't know what to do (this kind of question is typically 
considered out of the scope of application protocol definitions), and 
thus let the user decide. Of course, the user is very unlikely to 
understand the security impact of session cache or name-based 
certificate settings, and this is how we end up with the kind of attacks 
I demonstrated at Black Hat.

SPDY is an interesting case, as it does specify a clear resumption 
policy (even though, I must against stress out again, this policy 
technically allows resumption between any two HTTP origins as long as 
they appear in the same certificate; thus, CVE-2014-3166 does not 
violate any TLS or HTTP specification and cannot be considered an 
implementation bug). This policy should be interpreted as an 
authorization function for TLS authentication. In a full handshake, 
there is a well-specified and widely-adopted authorization function 
defined in RFC 5280. The problem I am pointing out is that the SPDY and 
PKIX authorization functions are incompatible. Thus, TLS features that 
assume PKIX authorization, such as SNI or ChannelID, may not guarantee 
the same security properties under SPDY authorization. Similarly, 
certain PKIX extensions will also fail under SPDY authorization, most 
notably certificate pinning.

 From the TLS viewpoint, it is reasonable to consider authorization 
outside the scope of the protocol. However, for the security of TLS, 
authentication and authorization must critically be preserved by 
resumption, as it is entirely a protocol feature that currently occurs 
without any application involvement. The issue may disappear in TLS 1.3 
if resumption is removed, but in current versions, the use of different 
authorization policies for full handshakes and resumption should be 
considered a weakness, which can be exploited.

Speaking of this, I have to disagree with your claim that attacks in 
this class are difficult to exploit. It may be true if you compare these 
attacks to heartbleed or browser memory bugs. However, compared to 
BEAST, Lucky13 or triple handshake, these attacks are orders of 
magnitude more exploitable.

Best,

Antoine Delignat-Lavaud