Thank you for the reply. Your point makes a lot of sense. But you are describing a security exploit. This begs the question: Does this mean that a certificate is not supposed to be issued (ever) to an IP i.e. CN=IP? 1) But if this is a possible use case, then how can we solve the problem I describe? Shouldn't the library handle this scenario? 2) If it is not a possible use case, then why have I observed that IE and Firefox do not complaint when receiving a certificate with CN an IP? Note that in (1) in relation to the security issue you correctly address, I would expect that this is a responsibility delegated to the user, to secure its PC and not have e.g. the host file tampered by a malicious person Regards
From: Sam Crawford <[email protected]> To: HttpClient User Discussion <[email protected]>; am am <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Wednesday, August 17, 2011 10:55 PM Subject: Re: HttpClient / SSL STRICT_HOSTNAME_VERIFIER Hello, This is not a bug. Your understanding of how SSL hostname verification works is flawed. The client will not perform reverse lookups and validate against the resulting domain. If that were the case I could set a reverse DNS entry for my IP address to microsoft.com and then fool clients into thinking they were accessing Microsoft when visiting my IP address. The CN in the certificate needs to match the hostname that you are visiting the target server with. Thanks, Sam On 17 August 2011 19:59, am am <[email protected]> wrote: > Hi, > > I have the following issue: > If I configure the SSLSocketFactory with STRICT_HOSTNAME_VERIFIER so that the > CN of the certificate send by the server is checked against the hostname, the > comparison is done only via strings. > What I mean is, that if the certificate (sent by the HTTPS server) has as CN > an IP e.g. 10.4.2.1 but the user writes in the address bar > https://secureserver/ (i.e. uses a domain name) but that name can be resolved > (reverse lookup) to the IP 10.4.2.1 e.g. is in the windows hosts file, I > still get the following exception: > javax.net.ssl.SSLException: hostname in certificate didn't match: > <secureserver> != <10.4.2.1> > at > org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:220) > at > org.apache.http.conn.ssl.StrictHostnameVerifier.verify(StrictHostnameVerifier.java:61) > at > org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149) > at > org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130) > at > org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:339) > at > org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:123) > at > org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:147) > at > org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108) > at > org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415) > at > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641) > at > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576) > at > org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554) > > I was expecting that the secureserver would be mapped to the IP and the > certificate would be accepted. > Is this a bug that has been fixed (I am using httpclient 4.0.1) or it is > intended to be this way? > > Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
