You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Alex Dupre (JIRA)" <ji...@apache.org> on 2011/03/07 17:09:59 UTC
[jira] Commented: (HTTPCLIENT-1051) SSL connections cannot be
established using resolvable IP address
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003412#comment-13003412 ]
Alex Dupre commented on HTTPCLIENT-1051:
----------------------------------------
Well, I looked at the patch. It should fix the issue (though not completely, since the reverse lookup could give a wrong/unresolvable hostname), but as you said it's a crude hack, and this opens to other security issues. Unfortunately the clean fix requires API modification.
You say using an IP address as CN is a hack, but actually using it as an ipAddress SubjectAlternativeName is perfectly valid.
The security issues arise from the fact that httpclient tries to match dns generated data (reverse lookups and now also resolved hostnames) instead of what the user actually typed, opening to DNS poisoning or connection redirect attacks.
First scenario:
- user wants to connect to 1.2.3.4
- DNS reverse lookup is xxx.yyy.zzz
- a malicious proxy redirects the connection to server 4.3.2.1
- server certificate contains CN or SAN set to xxx.yyy.zzz
- All OK (but shouldn't)
Second scenario:
- user wants to connect to xxx.yyy.zzz
- hacked DNS incorrectly resolve it to 1.2.3.4
- server certificate has CN or SAN set to 1.2.3.4
- The connection is established OK (but clearly shouldn't)
> SSL connections cannot be established using resolvable IP address
> -----------------------------------------------------------------
>
> Key: HTTPCLIENT-1051
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1051
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpConn
> Affects Versions: 4.1 Final
> Reporter: Alex Dupre
> Priority: Minor
> Fix For: 4.2 Final
>
>
> HttpClient 4.1 introduced a regression in establishing SSL connections to remote peers (it seems this is a common regression for major httpclient updates, see HTTPCLIENT-803).
> The new SSLSocketFactory.connectSocket method calls the X509HostnameVerifier with InetSocketAddress.getHostName() parameter. When the selected IP address has a reverse lookup name, the verifier is called with the resolved name, and so the IP check fails.
> 4.0 release checked for original ip/hostname, but this cannot be done with the new connectSocket() method.
> The TestHostnameVerifier.java only checks 127.0.0.1/.2 and so masked the issue, because the matching certificate has both "localhost" and "127.0.0.1", but actually only "localhost" is matched. A test case with 8.8.8.8 would be better.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org