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