hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Gl├╝ck <...@odi.ch>
Subject Re: [httpclient] [ssl] 4.0's CN verification might cause some headaches for users
Date Tue, 30 Jan 2007 08:55:54 GMT

Julius Davies wrote:
> As we get closer to the 4.0 release, I have one "titanic + iceberg"
> feeling.  Here's the head's up.
> This bug fix introduces a subtle, yet potentially devastating change
> to the default behaviour of "https://" when using httpclient-4.0:
> HTTPCLIENT-613 "https should check CN of x509 cert"
> I have this funny feeling that a lot of SOAP, REST, WS-*, and whatever
> else people call server-to-server HTTP is going to go *splat* when
> httpclient-4.0 starts making its way into JBoss, Websphere, Weblogic,
> Axis, and all those other stacks.

Integration of the new version of HttpClient is not going to be 
seamless. Our users will expect changes.

> Imagine even the simplest of scenarios:
> 1.  https://soap.mydomain.com/ has a beautiful proper cert from Verisign.
> 2.  But one of its java clients decided to save on the DNS lookup, and
> calls in (using httpclient) with "".
> 3.  Or people went to "https://google.com/" instead of
> "https://www.google.com/".
> 4.  The worst situation, though, is where it's a domain, but the
> locked-down business-to-business communication channel has no way to
> do the DNS lookup, since it doesn't have access to the target
> business's DNS.  It only has a measly little firewall opening for the
> one IP address.  So the consumer is actually forced to do
> "" unless they want to fool around with "/etc/hosts"!

Julius, such setups are inherently broken. There is nothing to save 
people who design crap like this. Somebody call me arrogant :-)

I can tell a similar story from the mobile world. We had an application 
running on a Sony P900. All worked well until the customer started using 
a new generation of the same phone. Its new OS was performing stricter 
checks on the code signing certificate and promptly refused to install 
our app because it was using only a self-signed one. Of course we fixed 
our signing procedure and not the phone.

> Do others have this nervous feeling?  Frankly, I feel we have no
> choice.  We're missing a critical piece of public PKI without it.  And
> thank goodness we support wildcards.  That will help.  But nonetheless
> I have a feeling best summed up by one word:
> Gulp.
> Just before 4.0 has its first RC, I think we should prepare for this
> issue on the wiki and even on the main webpage.

Of course I find it a good idea to document the new behaviour. This way 
integrators can easily find a solution when they get bug reports.

> =================================================
> FAQ - My "https://" connections worked great with httpclient-3.x, but
> ever since I upgraded to httpclient-4.x, my https connections are
> broken with this error message:
> javax.net.ssl.SSLException: hostname in certificate didn't match:
> <foo.com> != <bar.com>
> ------------------------------------
> Answer:
> Find out what domain the Certificate is valid for.  The error message
> should tell you.  Change your use of httpclient to use that domain
> exactly.
> If you see:  <foo.com> != <bar.com>
> Then change your httpclient calls from "https://foo.com/" to 
> "https://bar.com/".
> =================================================
> People were talking about "scheme" on this thread recently.  Can we
> provide the following two schemes right out of the box?

Yeah, why not. Although I am not a big fan of this abuse of schemes. You 
could do the same with a simple paramter to the request.

> https-no-host-verify://
> - This one checks the server's certificate for a valid
> Certificate-Chain + TrustAnchor, and requires that the server's cert
> be non-expired.  But this scheme doesn't verify the CN field of the
> certificate.  Behaves like "https://" under httpclient-3.0 and
> httpclient-2.0.
> (Or maybe call it  https-no-cn-check://?)  (other ideas?)

Maybe add one that fits the common practice of self-signed certs: 

Some admins actually believe that it's enough to have a self-signed 
cert, because it's the first thing in all the documentation and even 
generated semi-automatically by some linux distros...

> https-completely-insecure://

Well, it *does* encryption. So it's not completely insecure in a network 
without men-in-the-middle. At least it prevents accidential eavesdropping.

> - This one doesn't check CN, doesn't check expiry, and doesn't check
> for valid certificate chain + TrustAnchor.  This one is completely
> vulnerable to man-in-the-middle attacks, and should be avoided if at
> all possible, even for development environments, since it's such a bad
> habit that always seems to find a way into production.  Friends don't
> let friends use "https-completely-insecure://", even in the privacy of
> their own development environments.  We provide this scheme only as an
> evil temptation for you to resist.  It is not meant to ever be used.
> Yes, that's right.  Never use this one.
> (The old convention was "https-easy://" but I don't think "easy" isn't
> scaring people enough.)

[web]  http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp]  key 0x81CF3416
        finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416

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

View raw message