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