hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Davies" <juliusdav...@gmail.com>
Subject [httpclient] [ssl] 4.0's CN verification might cause some headaches for users
Date Tue, 30 Jan 2007 03:59:11 GMT
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.

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 "https://1.2.3.4/".

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
"https://1.2.3.4/" unless they want to fool around with "/etc/hosts"!

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.

=================================================
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?

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?)


https-completely-insecure://
- 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.)


-- 
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

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


Mime
View raw message