Re: [TLS] Inter-protocol attacks

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

Le 8/15/2014 2:56 AM, Martin Rex a écrit :
> But I still fail to see how session resumption would aggravate
> any bogosities performed by applications as long as the servers
> certificates on both handshakes (resumption an full)
> will properly *PASS* the usual server endpoint identification checks,
> which is what has been asserted.

As I explained before, the reason why it is the case is because TLS 
authorization is not context free: it depends on the application context.

In HTTP, application context boils down to origin, because the same 
origin policy is the only security context that makes sense in a browser.

Any TLS authorization for the Web that uses a context broader than 
origin is going to be a source of attack. This applies to both server 
and client. The problem with resumption is that unlike full handshakes, 
it uses implicit authorization. This can be easily blamed on protocol 
implementations, but TLS could have made resumption authorization more 
explicit.

On the server side, most web servers use a very simple authorization 
policy, which is basically "return true" regardless of the context. This 
is bad, because there are many reasons why a server would want to reject 
certain resumption requests, in particular when the application context 
(domain / SNI) of the resumption is different from the one in the 
initial connection. For instance, if the session being resumed is user 
authenticated, the server may want to use a different CA on the domain 
of the resumption, or an anonymous session. It may also prefer to use 
another certificate (such as an extended validation one) for this domain 
(even though the initial one may also work, say because it has a 
wildcard), or a different cipher, or avoid using the same Channel ID, or 
many other reasons. The new domain of the resumption may not be handled 
by the server (in fact, if the server uses multiple certificates, or a 
shared ticket key, it can even be that the requested domain is not in 
the certificate of the original session), in which case authorizing the 
resumption is guaranteed to break the same origin policy. These are all 
real attacks that can be found against top websites (see https://bh.ht.vc).

On the client side, clients typically use a resumption policy based on 
the domain associated with the session. This works great for HTTPS 
because protocol+domain is almost as good as origin (port being part of 
origin is a mistake). However, SPDY uses a resumption policy that 
assumes that authorization of the initial connection extends to other 
domains in the certificate. This is not the case: the original 
authorization was granted in a different application context, and it is 
in fact necessary to re-authorize the connection in the new context. See 
http://youtu.be/7zNWKTDs99g for a concrete exploit.

Overall, I am well aware that little can be done in the TLS protocol to 
solve the shortcomings of application authorization. Since SNI provides 
a good application context indication even outside HTTPS, the change 
that I was initially proposing to OpenSSL and Nginx several months ago 
was to enforce that the SNI may not change when a session is resumed. 
However, this restriction is not compatible with SPDY, and almost all 
servers continue to accept resumption with a different SNI currently.

Best,

Antoine Delignat-Lavaud