hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Crawford <samcrawf...@gmail.com>
Subject Re: HttpClient / SSL STRICT_HOSTNAME_VERIFIER
Date Fri, 19 Aug 2011 18:25:06 GMT
All I can do is direct your attention to section 3.1 of RFC2818
[http://www.ietf.org/rfc/rfc2818.txt]. This refers to the hostname
matching the subject name of the certificate. It does not specifically
preclude doing reverse DNS lookups, but absence of this must not be
treated as acquiescence. I am not aware of any browser implementations
that support traversing reverse lookups as you describe - it's a
gaping security hole.

I'll reiterate my earlier example to demonstrate why trusting reverse
lookups is a very bad idea in the general case:

Suppose I have an SSL certificate issued to me from a trusted
authority for my IP address (like you suggested in your original
email). Suppose I set a reverse DNS entry for my IP to microsoft.com.
Many ISPs permit this, and there is absolutely no restriction on what
anyone can set for a reverse DNS record. Now suppose your SSL client
implementation supported matching by IP and also by reverse lookup.
There are now a very large number of new security holes opened up:

1) As you pointed out in your reply, the "hosts" file in your
workstation could be modified to set a local mapping between my IP and
microsoft.com.
2) An unscrupulous employee at your ISP could change their DNS servers
to set a reverse DNS entry for my (malicious) IP to microsoft.com
3) Someone in your office/home could alter the settings on your home
router to change DNS servers to a compromised set
4) Someone with access to *any* point between you and your ISPs DNS
servers could install a device that intercepted and modified
particular DNS requests/responses

These are just a few of the potential areas of attack. As you'll see,
by allowing certificates to match upon reverse lookups we've
effectively nullified the protection offered by SSL hostname
verification. It just becomes a case of injecting a malicious DNS
entry.

I hope this helps,

Sam


On 19 August 2011 18:22, am am <akmeref@yahoo.com> wrote:
> Thank your for your help. I will study these.
> One last question though.
> Since I am being asked to do this and my understanding is that this may be a bad idea,
I was wondering if there is some reference e.g. in an RFC (or some other documentation) that
either mandates to avoid this (i.e. reverse lookup) or at least suggests not to do it.
> I mean, ok I go ahead and do it but I would like to know how it is the best/standard
practice for this.
> Any info/reference is highly appreciated. Thank you for your time
>
> Regards
>
> From: Sam Crawford <samcrawford@gmail.com>
> To: HttpClient User Discussion <httpclient-users@hc.apache.org>; am am <akmeref@yahoo.com>
> Cc: "olegk@apache.org" <olegk@apache.org>
> Sent: Friday, August 19, 2011 12:10 PM
> Subject: Re: HttpClient / SSL STRICT_HOSTNAME_VERIFIER
>
> Take a look at http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/conn/ssl/StrictHostnameVerifier.html
> and potentially check out the source for it too.
>
> I note that the docs for that class suggest that names in the
> 'subject-alt' fields of the certificate will also be accepted.
> Therefore, one possible option for you is to set subject-alt names in
> your SSL cert. Assuming you're working with self-signed certificates
> this should be straightforward.
>
> Alternatively you could write your own hostname verifier. The
> StrictHostnameVerifier (referenced above and also in your original
> stacktrace) is the default one, but there are others
> (AllowAllHostnameVerifier for example), and you could write your own
> that ran a reverse DNS lookup. You need to set the HostnameVerifier on
> the SSLSocketFactory.
>
> Thanks,
>
> Sam
>
>
>
> On 18 August 2011 15:51, am am <akmeref@yahoo.com> wrote:
>> Thank you for the response Oleg.
>> So the hostname comparison is always done as a literal strings?
>> There is no check if the name typed by the user can be mapped to the IP that the
certificate is issued?
>> 1)I am wondering (since perhaps erroneously I was expecting some DNS lookup) is there
an RFC recomending to do a literal comparison or is it just a common practice?
>> 2)If I wanted to do the lookup would I be able to implement my custom hostname verifier?
But only to customize the behavior on this part if needed. If you have a reference it would
be highly appreciated
>>
>> Regards
>>
>> From: Oleg Kalnichevski <olegk@apache.org>
>> To: HttpClient User Discussion <httpclient-users@hc.apache.org>
>> Sent: Thursday, August 18, 2011 5:36 PM
>> Subject: Re: HttpClient / SSL STRICT_HOSTNAME_VERIFIER
>>
>> On Wed, 2011-08-17 at 13:56 -0700, am am wrote:
>>> 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?
>>
>> No, it does not. CN can be an IP. However, in this case one must always
>> connect to the host by its IP in order for the hostname verification to
>> succeed.
>>
>> Oleg
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message