So I created an issue for this: https://issues.apache.org/jira/browse/HTTPCLIENT-1182
I attached the small patch that it would take. I made and tested it with 4.1.3, but it should work with 4.2 as well. I don't think there is much of a downside risk to this. The only think I can really think of is that the internal SSLSocketFactory is not completely private...meaning that whatever code passed in the socket factory could still be using it separately. Not sure if this is a much of an issue though. Hopefully this can be included in some near-future release. Thanks, Mark -----Original Message----- From: Mark Claassen [mailto:[email protected]] Sent: Monday, April 09, 2012 4:24 PM To: 'HttpClient User Discussion' Subject: RE: Access to "system" SSL socket factory. I only included the hostname resolver in my constructor because it was a final variable. > There is a SSLSocketFactory(SSLContext, X509HostnameVerifier) constructor > which is effectively equivalent to > SSLSocketFactory(javax.net.ssl.SSLSocketFactory X509HostnameVerifier) as far > as I can tell. I don't think so. This is the similar to what is in 4.2 beta1. I think I just need to use the default one from HttpsURLConnection. All the certificate stuff is handled internally to Webstart. Webstart has its own keystore information, but can also access the System's. I have not asked the Oracle deployment folks for all these gritty details, but the wrapping concept seems to work. I could try to check with Oracle, but I don't think another similar one could be created. I think I will submit a patch to HttpClient as you suggested and see what happens. Mark -----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Monday, April 09, 2012 4:11 PM To: HttpClient User Discussion Subject: RE: Access to "system" SSL socket factory. 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:[email protected]] > Sent: Wednesday, April 04, 2012 5:01 PM > To: [email protected] > 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: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
