hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HTTPCLIENT-718) SSL verification has no effect when creating detached sockets
Date Sat, 15 Dec 2007 17:36:45 GMT

     [ 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).  


> 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

View raw message