[TLS] Re: when is it ok to resume a cached SSL/TLS session

Martin Rex <martin.rex@sap.com> wrote:

> Eric Rescorla wrote:
> > 
> > Yes, it's discussed extensively in the SBR04 paper on Client-Side
> > Session Caching.
> > 
> > Shacham, H., Boneh, D., and E. Rescorla, "Client-side
> > caching for TLS", Transactions on Information and System
> > Security (TISSEC) , Volume 7, Issue 4, November 2004.
> 
> Since you didn't include an URL, I assume this isn't available online
> anwhere.

No, I just forgot.

http://www.hovav.net/dist/sslex.pdf

> We have just been reported by one of our customers what I consider
> a bug in the client side SSL/TLS session cache of a popular Browser,
> failing on a flawed assumption.
> 
> Scenario:  A host running two seperate SSL/TLS secured services
> (a J2EE- and a C/C++-built serice) on different TCP-Ports using
> seperate SSL/TLS (one is pure Java, the other pure C) implementations
> that differ in the highest supported protocol version.
> 
> The Service with the newer implementation is the "main service"
> or entry point, and it sometimes generates URLs
> referencing the other service (same host, different TCP-Port)
> with the older SSL/TLS implementation.
> 
> 
> The problem: The popular browser, when trying to access the older
> SSL/TLS implementation on a different TCP-Port is sending a
> session ID from the newer SSL/TLS implementation, apparently trying
> to resume an existing SSL session in the client-side session cache.
> 
> The server doesn't recognize that session and replies with
> a Server Hello containing his highest protocol version, plus
> plus server certificate message plus client cert request plus
> server hello done.  The popular Web Browser closes the network
> connection without sending any kind of SSL alert and shows
> "Page cannot be displayed" to the user.
> 
> 
> I firmly believe that this is a conceptual flaw on the client
> side, making a flawed assumption about when a cached SSL session
> can be expected to be resumable.

ISTM that there are two issues here:

1. Whether the client should have offered asession ID.
2. Whether it should have choked when the server refused.

Without taking a position on the first, which I think is tricky,
the client should definitely not have choked. Servers can always
refuse to accept a resumption.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls