hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Hicks" <jehi...@novell.com>
Subject Re: Force-close connections queston
Date Thu, 06 Jul 2006 19:22:25 GMT
We are using the EasySSLProtocolSocketFactory written by Oleg which is under com.sun.net.ssl.*.
I wasn't able to see a method for SSLContext called getClientSessionContext().
If there is a known way to invalidate the session using this class, that would be great. With
this class we are getting, what appears to be, one full handshake that is being shared across
all threads that are running instead of getting one full handshake for each thread (which
is what a browser does).
 
However, since I couldn't find that method, instead I tried a modified version of the EasySSLProtocolSocketFactory
class which uses the javax.net.ssl.* classes. Using that, it seems that ALL SSL handshakes
are full and that none of them are abbreviated. It didn't seem to matter what I set the session
cache size or session timeout to, I always got the same results. (I was trying to set these
within the getEasySSLSocketFactory() method.) It also didn't seem to matter if I used the
MultiThreadedHttpClientManger or my own that force-closes the HTTP connections.
Where should I be making the call to SSLSocket.getSession() to try and invalidate the session
there?
 
Am I missing something basic here? If I'm not being clear enough, please let me know.
 
 
Jeremy Hicks
Novell, Inc., the leading provider of information solutions
http://www.novell.com 

>>> Ortwin Glück <odi@odi.ch> 6/27/2006 2:16 PM >>>
Jeremy Hicks wrote:
> We have written a client that logs into a web application and then gets
> redirected to a web resource. We want to use SSL during this process.
> Everything seems to be working fine, but we noticed that abbreviated
> handshakes are being done instead of a full handshake. 

Jeremy,

Here is my understanding of the situation:

___________________________
SSL session != HTTP session

SSL is a stateful protocol. That's why there is the term "SSL session".
As SSL is not something specific to HTML this session has nothing to do
with HTTP session state (cookies, etc.). More specificly this session is
not tied to a single connection. Like a HTTP session it usually spans
multiple connections between the same endpoints.

_______________________
SSL session stores keys

SSL establishes a key pair with the host during a full handshake. This
key pair is expensive (asymmetric encryption is slow) to generate. It is
used to transfer a symmetric key (symmetric encryption is fast). This
symmetric key and the asymmatric pair is subsequently cached in the SSL
session. Typicall the key will expire after 24 hours and a new one will
be generated.

The abbreviated handshake uses this cached information to resume the
session in a secure way with less computational overhead (by simply
reusing the symmetric key).

________________________
Java SSL implementations

JSSE is the Java standard for SSL implementations. Its interfaces are in
javax.net.ssl. There you find the class SSLSession:
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSession.html 

SSL implementations have to implement this interface. The interface
provides an invalidate() method.

Access to the SSLSession object is possible through:

* SSLSocket.getSession()
* SSLContext.getInstance(...).getClientSessionContext().getSession(...)

The client SSLSessionContext
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSessionContext.html 
also has methods to control the session cache size and the session
timeout. This may be useful in your situation.

Hope that helps.

Ortwin Glück

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org 
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message