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

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.

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.

The problem is not with the client sending an existing session ID,
it is about dealing with the servers reply during the SSL/TLS handshake.
 - a server on a different port might not be sharing the session
   cache with the other
 - a server on a different port migt be using an entirely different
   SSL/TLS protocol implementation supporting different protocol
   versions and extensions
 - a server on a different port might be using a seperate server cert
 - a server on a different port might be sending/using an independent
   list of trusted CAs in a client certificate request

In our customers case, the Browser might be aborting thinking that
the a version rollback attack is being performed, but honestly, I don't
know what the problem is.  The browsers SSL implementation is
extremely poor/broken when reporting errors.

-Martin

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