You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "bitfire (JIRA)" <ji...@apache.org> on 2015/01/18 16:42:35 UTC
[jira] [Comment Edited] (HTTPCLIENT-1591) SNI doesn't work in
Android port for proxied connections
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14281833#comment-14281833 ]
bitfire edited comment on HTTPCLIENT-1591 at 1/18/15 3:42 PM:
--------------------------------------------------------------
I have now tested the new SSLConnectionSocketFactory. SNI is still not available for Android >= 2.3 and <= 4.1 because of these lines:
{code:java}
// Android specific code to enable SNI
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) {
if (Log.isLoggable(TAG, Log.DEBUG)) {
Log.d(TAG, "Enabling SNI for " + target);
}
try {
Method method = sslsock.getClass().getMethod("setHostname", String.class);
method.invoke(sslsock, target);
} catch (Exception ex) {
if (Log.isLoggable(TAG, Log.DEBUG)) {
Log.d(TAG, "SNI configuration failed", ex);
}
}
}
{code}
setHostname is available (via reflection and undocumented) since Android 2.3 while SSLCertificateSocketFactory::setHostname() is documented, but only available since API level 17 (Android 4.2).
Since you don't use SSLCertificateSocketFactory at all, there's no reason to limit the setHostname() call to Jelly Bean MR1+. For instance, on my Galaxy Note 10.1 with Android 4.1, the current Apache SSLConnectionSocketFactory doesn't provide SNI although setHostname is available.
Proposed fix (tested): Just remove the check for API level 17+. If SNI is not available because the Android version is <2.3, reflection will fail anyway.
was (Author: bitfire):
I have now tested the new SSLConnectionSocketFactory. SNI is still not available for Android >= 2.3 and <= 4.1 because of these lines:
// Android specific code to enable SNI
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) {
if (Log.isLoggable(TAG, Log.DEBUG)) {
Log.d(TAG, "Enabling SNI for " + target);
}
try {
Method method = sslsock.getClass().getMethod("setHostname", String.class);
method.invoke(sslsock, target);
} catch (Exception ex) {
if (Log.isLoggable(TAG, Log.DEBUG)) {
Log.d(TAG, "SNI configuration failed", ex);
}
}
}
setHostname is available (via reflection and undocumented) since Android 2.3 while SSLCertificateSocketFactory::setHostname() is documented, but only available since API level 17 (Android 4.2).
Since you don't use SSLCertificateSocketFactory at all, there's no reason to limit the setHostname() call to Jelly Bean MR1+. For instance, on my Galaxy Note 10.1 with Android 4.1, the current Apache SSLConnectionSocketFactory doesn't provide SNI although setHostname is available.
Proposed fix (tested): Just remove the check for API level 17+. If SNI is not available because the Android version is <2.3, reflection will fail anyway.
> SNI doesn't work in Android port for proxied connections
> --------------------------------------------------------
>
> Key: HTTPCLIENT-1591
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1591
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpConn
> Affects Versions: 4.3.5
> Reporter: bitfire
> Fix For: 4.3.5.1-android
>
>
> Edit: for PROXIED connections
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org