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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
