> -----Original Message-----
> From: Oleg Kalnichevski [mailto:[email protected]]
> Sent: Tuesday, May 17, 2011 3:42 AM
> To: HttpClient User Discussion
> Subject: Re: Looking at how I would implement a particular custom ssl
> socket factory with httpclient 4.1.1
>
> On Mon, 2011-05-16 at 18:10 +0000, KARR, DAVID (ATTSI) wrote:
> > A week or so ago I had to implement a custom ssl socket factory to do
> some specialized hostname verification.
> >
> > For background, we had been connecting to a "front-end" server that
> was presenting a SSL cert with a context name matching that server
> name. In fact, that cert is provided by a server "underneath" that
> front server. Due to certain network issues, we had to change our
> client code to directly connect to that "underneath" server.
> Unfortunately, that meant that hostname verification was now failing,
> and we don't want to turn off hostname verification. So, I implemented
> a ssl socket factory that gets constructed with an "alternate CN",
> which I'm passing in the original "front server" name for. This is
> working fine.
> >
> > I did this with HttpClient 3.0.1. I'm now researching what will be
> required to upgrade our code base to use the latest HttpClient, 4.1.1
> at this point.
> >
> > I've been looking at the new documentation, and I noticed the
> "BrowserCompatHostnameVerifier" option. From what I can see, this
> isn't quite what I need. Will I still need a custom ssl socket factory
> for this, or is some of what I need now "canned" in the latest
> HttpClient?
> >
>
> HttpClient 4.x should be able to handle alternate CNs in certificates
> when performing hostname verification out of the box.
If I'm understanding what you're saying, it will handle certs where the
alternate CNs are specified in the certificate? That's not my situation. My
code is going to have to supply the alternate CN.
In HttpClient 3.0.1, I implemented a custom SecureProtocolSocketFactory. In
HttpClient 4.1.1, I believe I have to create a SSLSocketFactory, but with a
custom hostname verifier.
I've gotten this working, but I was confused a bit by the fact that the "sense"
of my comparison has switched between the old code and the new code.
For example, using a made-up hostname and cert CN, the host I connect to is
"www.stuff.cnn.junk.com", and the cert I get has a CN of "www.cnn.com". In my
old SecureProtocolSocketFactory, I provided an alternate CN of "www.cnn.com".
Without that, it would fail hostname verification. In my new hostname
verifier, I've defined the following method:
public void verify(String host, String[] cns, String[] subjectAlts) throws
SSLException {
String[] mergedAltCNs =
new String[(subjectAlts != null ? subjectAlts.length : 0) +
getAlternateContextNameList().size()];
mergedAltCNs = getAlternateContextNameList().toArray(mergedAltCNs);
if (subjectAlts != null)
System.arraycopy(subjectAlts, 0, mergedAltCNs,
getAlternateContextNameList().size(), subjectAlts.length);
verify(host, cns, mergedAltCNs, false);
}
Using this schema, I have to supply an alternate CN of "www.stuff.cnn.junk.com"
in order for this to pass. This seems odd to me. I'm starting to wonder what
I should be verifying here.
If I understand the security issues correctly, I have to defend against the
unlikely possibility that someone poisons DNS and makes me go to a completely
different host. If I use this code, I don't think I would detect anything
wrong. It seems like I really should be validating the CNs in the cert, not
the hostname I got the cert from.
