You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Jeremy Hicks <je...@novell.com> on 2006/07/06 21:22:25 UTC
Re: Force-close connections queston
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 <od...@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
Re: Force-close connections queston
Posted by Ortwin Glück <od...@odi.ch>.
Jeremy Hicks wrote:
> EasySSLProtocolSocketFactory written by Oleg uses the SSL libraries
> which are under com.sun.net.ssl as opposed to the ones you suggested
> which are under javax.net.ssl.
Ah, now I understand. That was changed in February:
http://issues.apache.org/jira/browse/HTTPCLIENT-559
> There is no getClientSessionContext() method when using the SSL
> libraries from com.sun.net.ssl. It is only under javax.net.ssl.
Of course.
> I'll try this out. Thanks again for your help.
Prego
Ortwin
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Jeremy Hicks <je...@novell.com>.
EasySSLProtocolSocketFactory written by Oleg uses the SSL libraries which are under com.sun.net.ssl as opposed to the ones you suggested which are under javax.net.ssl.
There is no getClientSessionContext() method when using the SSL libraries from com.sun.net.ssl. It is only under javax.net.ssl.
I found a modified version of Oleg's EasySSLProtocolSocketFactory class online which uses the javax.net.ssl libraries instead. With this modified version, I was able to use the methods you suggested (setSessionCacheSize, etc) but I wasn't sure I was using them in the correct place and no matter what I did, it didn't seem to make any difference. (I was trying to set these within the getEasySSLSocketFactory() method.)
>>I think the best place to invalidate the session is from a custom
>>connection manager in its releaseConnection method like so:
>>((SSLSocket) conn.getSocket()).getSession().invalidate();
I'll try this out. Thanks again for your help.
Jeremy Hicks
Novell, Inc., the leading provider of information solutions
http://www.novell.com
>>> Ortwin Glück odi@odi.ch> 7/7/2006 2:33 AM >> ( mailto:odi@odi.ch> )
Jeremy Hicks wrote:
> We are using the EasySSLProtocolSocketFactory written by Oleg which
> is under com.sun.net.ssl.*.
Huh, what is under com.sun?
> I wasn't able to see a method for
> SSLContext called getClientSessionContext().
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html#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).
Yes, that's true. This implementation is not perfect. It's a basis.
We happily accept patches, however.
> 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.
I fail to understand...
> Using that, it seems that ALL SSL
> handshakes are full and that none of them are abbreviated.
Maybe you are not keeping any SSL sessions?
> 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?
I think the best place to invalidate the session is from a custom
connection manager in its releaseConnection method like so:
((SSLSocket) conn.getSocket()).getSession().invalidate();
> Am I missing something basic here? If I'm not being clear enough,
> please let me know.
>
Hope that helps
Ortwin Glück
> Jeremy Hicks Novell, Inc., the leading provider of information
> solutions http://www.novell.com ( http://www.novell.com/ )
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Roland Weber <ht...@dubioso.net>.
Hello Jeremy,
> Okay, that makes sense. So you are saying that the SSLSocket socket is
> set to null after that first line. Why would it return null? Why
> wouldn't the call to getSocket() return the socket?
I have no idea. Maybe there is no socket (anymore)?
Why don't you look into the code and put some debug output there?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Jeremy Hicks <je...@novell.com>.
Okay, that makes sense. So you are saying that the SSLSocket socket is
set to null after that first line. Why would it return null? Why
wouldn't the call to getSocket() return the socket?
Thanks again
Jeremy Hicks
Novell, Inc., the leading provider of information solutions
http://www.novell.com
>>> Roland Weber <ht...@dubioso.net> 07/17/06 11:53 AM >>>
Hi Jeremy,
> SSLSocket socket = (SSLSocket)MyConnectionHelper.getSocket(conn);
> SSLSession session = socket.getSession();
> session.invalidate();
>
> The exception seems to be coming from:
>
> SSLSession session = socket.getSession();
>
> I guess I don't understand why every SSLSocket wouldn't have a
session.
Think again. A NullPointerException isn't thrown because a method
returns null, it's thrown because the object on which you are calling
the method is null.
An SSLSocket wouldn't have a session if it hasn't been opened yet,
for starters. Communication problem? Handshake failure? Session
invalidated by server?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Roland Weber <ht...@dubioso.net>.
Hi Jeremy,
> SSLSocket socket = (SSLSocket)MyConnectionHelper.getSocket(conn);
> SSLSession session = socket.getSession();
> session.invalidate();
>
> The exception seems to be coming from:
>
> SSLSession session = socket.getSession();
>
> I guess I don't understand why every SSLSocket wouldn't have a session.
Think again. A NullPointerException isn't thrown because a method
returns null, it's thrown because the object on which you are calling
the method is null.
An SSLSocket wouldn't have a session if it hasn't been opened yet,
for starters. Communication problem? Handshake failure? Session
invalidated by server?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Jeremy Hicks <je...@novell.com>.
Okay, thanks for the idea of splitting it up. Now I have:
SSLSocket socket = (SSLSocket)MyConnectionHelper.getSocket(conn);
SSLSession session = socket.getSession();
session.invalidate();
The exception seems to be coming from:
SSLSession session = socket.getSession();
I guess I don't understand why every SSLSocket wouldn't have a session.
Thanks everybody for your patience.
Jeremy Hicks
Novell, Inc., the leading provider of information solutions
http://www.novell.com
>>> Roland Weber <ht...@dubioso.net> 07/17/06 11:15 AM >>>
Hi Jeremy,
> I get a NullPointerException on this line:
>
>
((SSLSocket)MyConnectionHelper.getSocket(conn)).getSession().invalidate();
>
> Can anybody tell why?
Either because getSocket(conn) returns null, or because
SSLSocket.getSession() returns null. How about splitting
this monster up into several lines to find out?
Also, how can you be sure that every SSLSocket has a
session? Connections might be released prematurely.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Roland Weber <ht...@dubioso.net>.
Hi Jeremy,
> I get a NullPointerException on this line:
>
> ((SSLSocket)MyConnectionHelper.getSocket(conn)).getSession().invalidate();
>
> Can anybody tell why?
Either because getSocket(conn) returns null, or because
SSLSocket.getSession() returns null. How about splitting
this monster up into several lines to find out?
Also, how can you be sure that every SSLSocket has a
session? Connections might be released prematurely.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Ortwin Glück <od...@odi.ch>.
Jeremy Hicks wrote:
> I get a NullPointerException on this line:
>
> ((SSLSocket)MyConnectionHelper.getSocket(conn)).getSession().invalidate();
>
>
> Can anybody tell why?
Maybe, because one of those reference is null? I am sure you can figure
out which one.
> Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Jeremy Hicks <je...@novell.com>.
Okay, I'm now trying with this Connection Helper class. Below is my
custom connection manager class:
import org.apache.commons.httpclient.*;
import javax.net.ssl.*;
public class MyHttpConnectionManager extends
MultiThreadedHttpConnectionManager
{
public void releaseConnection(final HttpConnection conn)
{
//TODO Need something here to check if we are SSL or not
try
{
// Getting a NullPointerException here. Why?
((SSLSocket)MyConnectionHelper.getSocket(conn)).getSession().invalidate();
}
catch(ClassCastException cce)
{
// It is okay, we are most likely just not running SSL.
}
if (conn == null)
{
return;
}
conn.close();
super.releaseConnection(conn);
}
}
I get a NullPointerException on this line:
((SSLSocket)MyConnectionHelper.getSocket(conn)).getSession().invalidate();
Can anybody tell why?
Thanks
Jeremy Hicks
Novell, Inc., the leading provider of information solutions
http://www.novell.com
>>> Roland Weber <ht...@dubioso.net> 07/08/06 10:49 AM >>>
Hello Jeremy,
> ((SSLSocket) conn.getSocket()).getSession().invalidate();
> won't work for me because the getSocket() call on the HttpConnection
conn is a protected method.
> I'm not within scope. What are my options?
Yet another design limitation of the 3.x codebase.
Easiest workaround is to get into scope:
package org.apache.commons.httpclient;
import java.net.Socket;
public final class MyConnectionHelper {
/** disabled constructor */
private MyConnectionHelper() {
}
public final static Socket getSocket(HttpConnection conn) {
return conn.getSocket();
}
}
I think you can rely on HttpClient not to define any classes
with a "My" prefix :-)
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Roland Weber <ht...@dubioso.net>.
Hello Jeremy,
> ((SSLSocket) conn.getSocket()).getSession().invalidate();
> won't work for me because the getSocket() call on the HttpConnection conn is a protected method.
> I'm not within scope. What are my options?
Yet another design limitation of the 3.x codebase.
Easiest workaround is to get into scope:
package org.apache.commons.httpclient;
import java.net.Socket;
public final class MyConnectionHelper {
/** disabled constructor */
private MyConnectionHelper() {
}
public final static Socket getSocket(HttpConnection conn) {
return conn.getSocket();
}
}
I think you can rely on HttpClient not to define any classes
with a "My" prefix :-)
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Jeremy Hicks <je...@novell.com>.
I found one problem here that I can't seem to figure out how to fix. This:
((SSLSocket) conn.getSocket()).getSession().invalidate();
won't work for me because the getSocket() call on the HttpConnection conn is a protected method. I'm not within scope. What are my options?
Thanks
Jeremy Hicks
Novell, Inc., the leading provider of information solutions
http://www.novell.com
>>> Ortwin Glück <od...@odi.ch> 7/7/2006 2:33 AM >>>
Jeremy Hicks wrote:
> We are using the EasySSLProtocolSocketFactory written by Oleg which
> is under com.sun.net.ssl.*.
Huh, what is under com.sun?
> I wasn't able to see a method for
> SSLContext called getClientSessionContext().
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html#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).
Yes, that's true. This implementation is not perfect. It's a basis.
We happily accept patches, however.
> 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.
I fail to understand...
> Using that, it seems that ALL SSL
> handshakes are full and that none of them are abbreviated.
Maybe you are not keeping any SSL sessions?
> 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?
I think the best place to invalidate the session is from a custom
connection manager in its releaseConnection method like so:
((SSLSocket) conn.getSocket()).getSession().invalidate();
> Am I missing something basic here? If I'm not being clear enough,
> please let me know.
>
Hope that helps
Ortwin Glück
> Jeremy Hicks Novell, Inc., the leading provider of information
> solutions http://www.novell.com ( http://www.novell.com/ )
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: Force-close connections queston
Posted by Ortwin Glück <od...@odi.ch>.
Jeremy Hicks wrote:
> We are using the EasySSLProtocolSocketFactory written by Oleg which
> is under com.sun.net.ssl.*.
Huh, what is under com.sun?
> I wasn't able to see a method for
> SSLContext called getClientSessionContext().
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html#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).
Yes, that's true. This implementation is not perfect. It's a basis.
We happily accept patches, however.
> 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.
I fail to understand...
> Using that, it seems that ALL SSL
> handshakes are full and that none of them are abbreviated.
Maybe you are not keeping any SSL sessions?
> 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?
I think the best place to invalidate the session is from a custom
connection manager in its releaseConnection method like so:
((SSLSocket) conn.getSocket()).getSession().invalidate();
> Am I missing something basic here? If I'm not being clear enough,
> please let me know.
>
Hope that helps
Ortwin Glück
> Jeremy Hicks Novell, Inc., the leading provider of information
> solutions http://www.novell.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org