hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Vasileff (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1119) Server Name Indication (SNI) Support
Date Tue, 19 Feb 2013 15:53:14 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581386#comment-13581386
] 

John Vasileff commented on HTTPCLIENT-1119:
-------------------------------------------

Let see if I can net this out:

1) (I think) Anyone who wants can create a custom X509HostnameVerifier that includes

if (socket instanceof sun.security.ssl.SSLSocketImpl)
      ((sun.security.ssl.SSLSocketImpl)socket).setHost(host);

But, they would be using an unpublished api (may break later), and would be dropping support
for JREs before 7.  They would also be using X509HostnameVerifier in a way not supported by
the API documentation (setting something in a "verifier" - seems dangerous, even if it would
work today.)

2) Reflection could added to #1 (as in the patch) to help with JRE compatibility. Any arguments
against the suggested patch would apply here as well, but to a greater degree: users of HttpClient
are a further step removed from the underlying TLS implementation, they are not necessarily
socket programming experts, and the funny use of a "verifier" api.

3) The patch (or similar) could be applied to HttpClient. As in #2, JRE compatibility would
be maintained. Leveraging an unpublished sun.x API isn't great, but it shouldn't break anything
(if it's not there at runtime, SNI simply won't be performed.) Some dislike reflection, but
without it, we can never leverage new features.

Through all of the prior discussion, I fail to see a concrete reason why the patch would cause
problems. It may be aesthetically displeasing to some, but... what are the practical downsides?
Pushing the burden of implementing this "TLS fix-up" to users of HttpClient has the practical
downsides mentioned above and previously.
                
> Server Name Indication (SNI) Support
> ------------------------------------
>
>                 Key: HTTPCLIENT-1119
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1119
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>            Reporter: Gus Power
>              Labels: sni, ssl, tls, vhost
>             Fix For: Future
>
>         Attachments: HTTPCLIENT-1119-support-SNI-on-Java-7-via-setHost-of.patch
>
>
> Provide support for Server Name Indication (SNI) support as per RFC 3546 (section 3.1).
> Currently attempting to connect to SNI enabled host 'expectedhost' over SSL using http
client results in an SSLException similar to:
> javax.net.ssl.SSLException: hostname in certificate didn't match: <expectedhost>
!= <defaulthost>
>   at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:220)
> We use SNI on some of our environments and were trying to use httpclient to automatically
test host access and availability.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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


Mime
View raw message