[
https://issues.apache.org/jira/browse/HTTPCLIENT-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-1346:
------------------------------------------
Fix Version/s: 4.2.6
Sounds reasonable. I still think that behavior of #getSession with regards to
i/o exception propagation is utterly silly, though.
Oleg
PS: Could you please submit the proposed changes as a patch?
> SSL handshake exceptions are hidden from application
> ----------------------------------------------------
>
> Key: HTTPCLIENT-1346
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1346
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.2.3
> Reporter: Pasi Eronen
> Fix For: 4.2.6
>
>
> When the SSL handshake fails for some reason, (e.g. TCP connection reset,
> socket read timeout, no common cipher suite found, expired certificate,
> untrusted certificate, server sends non-SSL garbage, etc.), all the
> application sees is "javax.net.ssl.SSLPeerUnverifiedException: peer not
> authenticated" (without any cause chain). This is rather unhelpful for
> troubleshooting SSL errors.
> According to the SSLSocket Javadocs, the SSL handshake can be initiated in
> three ways: calling startHandshake(), attempting to read or write data, or
> calling getSession(). The first two of these throw appropriate exceptions on
> failure (usually with cause chains indicating the root cause), while the
> third just returns a special session handshake with invalid ciphersuite
> SSL_NULL_WITH_NULL_NULL (and the actual cause of handshake failure is lost).
> Currently org.apache.http.conn.ssl.SSLSocketFactory uses the third approach
> (and does not even check for the invalid ciphersuite).
> Proposed fix: add call "sslsock.startHandshake();" after call to
> prepareSocket but before hostnameVerifier (which calls getSession). This
> requires also one-line change to TestSSLSocketFactory.java (change
> SSLPeerUnverifiedException to SSLHandshakeException).
> I tested this fix with five different cases (TCP connection reset, socket
> read timeout, expired certificate, self-signed certificate, and non-SSL
> server), and in all five cases, I now get a reasonably correct exception text
> (and a cause chain).
--
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]
