Re: Question on SSL caching

[JKemp <ke...@gmail.com>]

So, we put in a work around for this by setting the sslCacheTimeout property
to 10 seconds and setting our connections to time out after 15 seconds. 
That seems to ensure that the SSL session has already expired by the time we
try to establish a new connection and forces a fresh handshake from scratch.

The issue now is that whenever there's any sort of error between client and
server, it automatically is killing our connection and forcing a new one. 
But when this happens, the SSL session hasn't expired yet and we're left
with about 10 seconds of handshake failures before the session expires and
it forces a new handshake.

Is there any way to invalidate the SSL session whenever the connection is
closed?  This could also be a problem for us in production, because the
client that we're connecting to is setting up a load balancer to round robin
us between servers, but they're having the individual servers handle the SSL
sessions.  Meaning that we might get bounced from server to server with each
connection and the new server will have no knowledge of the SSL session we
had with the previous server.

--
View this message in context: http://cxf.547215.n5.nabble.com/Question-on-SSL-caching-tp5455499p5623282.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Question on SSL caching

[JKemp <ke...@gmail.com>]

Alright, we resolved the issue.  This turned out to be an issue with the
server that we were connecting to.  What was happening was that our SSL
Client Hello for our original request was using SSLv2.  The server responded
with the Server Hello with SSLv3, which our client accepted and we proceeded
with the connection over SSLv3.  However, on a subsequent connection, we
sent an SSLv3 Client Hello that tried to use the cached SSL session, which
the server rejected.  We couldn't figure out why this was the case and the
folks that owned the server we were connecting to were... less than helpful.

Just as an experiment, I changed our application to always use SSLv3:

		<http:tlsClientParameters
			secureSocketProtocol="SSLv3" sslCacheTimeout="10">
		</http:tlsClientParameters>

This resulted in them immediately rejecting our Client Hello, even when we
weren't using a cached SSL session.  They couldn't explain why their server
was rejecting the SSLv3 Client Hellos, so I just changed our application to
use TLS v1 and the problem went away:

		<http:tlsClientParameters
			secureSocketProtocol="TLS" sslCacheTimeout="10">
		</http:tlsClientParameters>

Fun times.



--
View this message in context: http://cxf.547215.n5.nabble.com/Question-on-SSL-caching-tp5455499p5725449.html
Sent from the cxf-user mailing list archive at Nabble.com.