Re: [TLS] SNI and tickets and resumption

[Brian Sniffen <[e-mail]>]

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

At least for HTTP, the changing SNI will indicate a change of cookie and
same-origin context.  But RFC 6066 says:

   If there is a mismatch between the server name used by the client
   application and the server name of the credential chosen by the
   server, this mismatch will become apparent when the client
   application performs the server endpoint identification, at which
   point the client application will have to decide whether to proceed
   with the communication.

So maybe the client applications all carefully follow this tricky
advice.

On the other hand, RFC 6066 also says:

   A server that implements [SNI] MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session. 

It doesn't sound like your server quite does that?

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies