[
https://issues.apache.org/jira/browse/HTTPCLIENT-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003488#comment-13003488
]
Alex Dupre commented on HTTPCLIENT-1051:
----------------------------------------
Hmm, my comment was not meant to revert the patch. The first scenario was
already exploitable and still is. Your patch is the "correct" solution without
breaking the API.
But to avoid any security issue (including the ones already present) the API
have to be changed.
> 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
>
> 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]
