hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject RE: Access to "system" SSL socket factory.
Date Mon, 09 Apr 2012 20:11:04 GMT
On Mon, 2012-04-09 at 15:18 -0400, Mark Claassen wrote:
> I have had some success wrapping the socket factory in HTTP Client (v4.1.3) and getting
that to work. :) However, I have a few
> questions:
> 
> First, how do you feel about having a constructor that would set the final variables
directly:
> - javax.net.ssl.SSLSocketFactory
> - HostNameResolver
> - X509HostnameVerifier
> Having this would have made what I needed to do very straight-forward and simple since
I could have just passed in the socket
> factory I wanted to use.
> 

Hi Mark

HostNameResolver has been deprecated in 4.2 because it does not support
multi-home hostnames. Moreover, the DNS resolution logic has been moved
from scheme socket factory level to the connection operator level.

There is a SSLSocketFactory(SSLContext, X509HostnameVerifier)
constructor which is effectively equivalent to
SSLSocketFactory(javax.net.ssl.SSLSocketFactory X509HostnameVerifier) as
far as I can tell. But by all of means feel free to submit a patch.

> Second, in this class there is a Socket created not through the SocketFactory in one
place, and I was wondering why.  Here is what
> it looks like in org.apache.http.conn.ssl.SSLSocketFactory
> 
>     public Socket connectSocket(
>             final Socket socket,
>             final InetSocketAddress remoteAddress,
>             final InetSocketAddress localAddress,
>             final HttpParams params) throws IOException, UnknownHostException, ConnectTimeoutException
{
>         if (remoteAddress == null) {
>             throw new IllegalArgumentException("Remote address may not be null");
>         }
>         if (params == null) {
>             throw new IllegalArgumentException("HTTP parameters may not be null");
>         }
> >>>>    Socket sock = socket != null ? socket : new Socket(); <<<<
> 
> Shouldn't this be
>         Socket sock = socket != null ? socket : socketfactory.createSocket();
> 

Yes, this is obviously conceptually wrong. Fixed in SVN trunk.

Oleg

> Later in the code, it then checks the Socket type, and since it will not be an SSL socket,
it will then call:
>         this.socketfactory.createSocket(sock, hostname, port, true);
> 
> This seemed an odd pattern to me.  I can see a potential reason for it, but wasn't sure
about it and was not sure if this would be a
> possible point of failure in my situation.
>
> Thanks,
> Mark
> 
> -----Original Message-----
> From: Mark Claassen [mailto:mac01@donnell.com] 
> Sent: Wednesday, April 04, 2012 5:01 PM
> To: httpclient-users@hc.apache.org
> Subject: Access to "system" SSL socket factory.
> 
> We are still using HttpClient 4.01 and were considering upgrading to 4.1, but I see a
feature we were using is gone.  In 4.01, there
> was a DEFAULT_FACTORY which was the defined from HttpsURLConnection.getDefaultSSLSocketFactory();
> 
> This was very useful to us.  The reason for this was because our app is launched by Java
Webstart.  When using the default socket
> factory, we can benefit from Webstart handling the prompting for things like host name
verification.
> 
> More importantly, however, was webstart's ability to interface with the Window's keystore.
 We have a client that uses certificated
> based authentication for their SSL connections.  Using the default socket factory makes
everything just work.  The users would get
> prompted for a certificate and then they could activate it off their hardware devices.
 (Presumably, then, the SSL encryption is
> handled by the device.  I have no idea how I would do this without webstart.)
> 
> I guess I would like to know what is my best path to take to get this working.  Could
I just subclass it and then override the
> connectSocket() methods?  I noticed that the javax SSLSocketFactory has similar createSocket()
methods...
> 
> Thanks,
> Mark
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 



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


Mime
View raw message