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 "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"!
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:
https-self-signed://
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
