Re: [TLS] SNI and tickets and resumption

[[e-mail] (Martin Rex)]

Antoine Delignat-Lavaud wrote:
> Le 8/11/2014 5:02 AM, Brian Sniffen a écrit :
>>> Essentially, whenever a full handshake would result in the use of the
>>> same server certificate as the resumption proposed by the client,
>>> my server will perform session resumption, and ingnore SNI mismatches.
>> So if a server has a giant SAN cert for `eff.org` and `nsa.gov`, and a
>> session with one is resumed to the other---that's unsurprising?  I don't
>> see a path all the way through to an attack, but it leads me to worry
>> about a web app and a web server interacting in this way.
> 
> Yes, it *is* indeed unsurprising: this behavior is the standard in SPDY 
> and in the current HTTP2 draft even though it goes against the spirit of 
> RFC 6066 -- see my message in the thread "inter-protocol attacks".

It is not against the *spirit* (aka underlying design) of TLS extension
server name indication, only against the current, formally provable
defective ad-hoc wording that was used to describe one aspect of the
behaviour (keep in mind that RFC at the "Proposed Standard" maturity
level must be assumed to contain defects such as this one.)


>
> Moreover, current webservers will also proceed with resumption even if 
> the SNI provided by the client would have resulted in the server picking 
> a different certificate.

This behaviour would be against the spirit of rfc6066, and against the
"principle of least surprise".  It would indicate a significant lack of
robustness when fiddling with the session cache lifetime on client or
sorver or when disabling the client-side or server-side session cache
would affect application behaviour / usage scenarios.


>
> This is why resumption can be used to bypass certificate validation
> - this problem is related to yet another TLS API problem with the
> SNI callback. In many cases, the application may not even get to see
> the certificate selection callback from TLS when doing resumption.


According to the TLS specification (last paragraph of Introduction),
the server endpoint identification is something that the application on
top of TLS performs, whereas TLS session caching and resumption is
something that happens transparently within the TLS protocol stack.

  Last sentence of Section 1. Introduction

  https://tools.ietf.org/html/rfc2246#page-4
  https://tools.ietf.org/html/rfc5246#page-5

                   how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.


The TLS client app ought to perform server endpoint identification
"interpret the authentication certificates exchanged" independent
of whether the TLS connection is established with a full TLS handshake
or and abbreviated TLS handshake (aka TLS session resume).

Normally, I would assume that the client-side session cache is organized/
indexed by the information that is used for server endpoint identification,
and a client should not be proposing session resumption of a cached session
that would fail server endpoint identification.


-Martin