Re: [TLS] Multiple Session Caches and SNI

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> > In addition to cache management aspects, the TLS server should keep
> > robustness in mind.  e.g. robustness against TLS clients with
> > a broken client-side TLS session cache management that will
> > recklessly propose a TLS session resume for a session (ID) originally
> > established with Mars to just about every earthling they're asked
> > to connect to later on.
> 
> Section 7.2.2 of RFC 5246 concerning Error Alerts handles this.  If
> a connection terminates with a fatal alert, the session associated
> with that connection MUST NOT be resumed.  So perhaps a server will
> try to resume the session once, but it will delete it from its cache
> when the handshake fails.  Other servers that don't recognize the
> session ID will perform full handshakes.

That appears to strict to me.  I would make the server delete
a session from his cache when an attempted resume results in a failure.
I can not currently think of an error (i.e. fatal alert) after a
mutual successful finished message verification that should cause
the server to flush the affected ssl session from his session cache.


> 
> > And before a TLS server checks for existence of a TLS session,
> > whose session ID is proposed in a ClientHello, it should determine
> > wheter it would be willing to establish a new session through
> > a full handshake based on the other information in the ClientHello
> > and under what conditions it would do so.
> 
> I do it the other way around -- after retrieving the session, checks
> are made to make sure the cipher suite and compression algorithm are
> listed in the ClientHello.  This is mandatory according to section
> 7.4.1.2.  The only other check I currently have is for the age of the
> session to make sure it is fresh enough.

An actual implementation will probably involve certains decisions
based more on personal taste than factual requirements.

The most important issue is consitent and predictable/deterministic
behaviour of the server, even when broken clients are involved.


> 
> > If the TLS server finds a TLS session with the proposed session ID
> > in his cache, it should then use the results from the previous
> > determination of the ClientHello parameters whether it is OK to
> > attempt to resume the cached session, or whether it is advised
> > to perform a full SSL handshake, because of a significant mismatch
> > of the newly determine session characteristics from those
> > of the cachend session identified by the client-proposed Session ID.
> 
> RFC 4366 states:
> 
>     -  If, on the other hand, the older session is resumed, then the
>        server MUST ignore the extensions and send a server hello
>        containing none of the extension types.  In this case, the
>        functionality of these extensions negotiated during the original
>        session initiation is applied to the resumed session.

Correct, but you should not read it backwards.

If the server agrees to resume (for whatever reason), the other
accompanying information in the ClientHello should NOT be used to
modify that cached session.

Does rfc-4366 say anywhere that the server _must_not_ involve the
parameters and extensions present in a ClientHello in his decision
to resume or not resume a cached SSL session when the client
includes a session id in the ClientHello handshake message?


-Martin