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

Martin Rex wrote:
> 
> 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.

After some further investigation I have been able to reproduce
the error on our machines.

It seems to be related to either the ciphersuite or the
(algorithm) of the server's certificate (RSA vs DSA).
The protocol version doesn't seem to matter in this case.

The customer has installed a DSA server certificate on the newer
J2EE service and an RSA server certificate on the older C/C++ service.

I've just reproduced this behaviour using an IIS with DSA certificate
and my own test-server with an RSA certificate on the same host
but different ports.

When I click an URL referencing the RSA-server on a page served
from the DSA-server, the browser aborts with "Page cannot be displayed".
When I hit "refresh", the page loads. (Maybe the browser invalidates
the client cache entry after the error).

-Martin

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