You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2007/12/15 18:36:45 UTC
[jira] Updated: (HTTPCLIENT-718) SSL verification has no effect
when creating detached sockets
[ https://issues.apache.org/jira/browse/HTTPCLIENT-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCLIENT-718:
-----------------------------------------
Summary: SSL verification has no effect when creating detached sockets (was: SSL verification occurs before setSoTimeout, which can lead to hangs)
Apparently we have a bigger problem here. SSL host verification is completely messed up at the moment. It is not executed at all when creating detached sockets (which is what HttpClient does per default). SSL host verification needs to be moved from the socket factory to an upper level (connection operator or connection manager).
Oleg
> SSL verification has no effect when creating detached sockets
> -------------------------------------------------------------
>
> Key: HTTPCLIENT-718
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-718
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.0 Alpha 2
> Reporter: peter royal
> Fix For: 4.0 Alpha 3
>
>
> partial thread dump:
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.read(SocketInputStream.java:129)
> at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
> at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:723)
> - locked <0x00002aaab87d9de0> (a java.lang.Object)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
> - locked <0x00002aaab87d9dc0> (a java.lang.Object)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.getSession(SSLSocketImpl.java:1757)
> at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:87)
> at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:295)
> at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:131)
> at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:143)
> at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:120)
> at org.apache.http.impl.client.DefaultClientRequestDirector.execute(DefaultClientRequestDirector.java:286)
> at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:452)
> at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:406)
> at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:365)
> ... this is because in DefaultClientConnectionOperator, prepareSocket (which sets any configured timeouts) isn't called until after SocketFactory.connectSocket. When using SSLSocketFactory, the default behavior is to verify the hostname, which opens a connection, and can block indefinitely.
> Simple workaround is to use the AllowAllHostnameVerifier which doesn't do any verification.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org