[
https://issues.apache.org/jira/browse/HTTPCORE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477189#comment-13477189
]
Scott Stanton commented on HTTPCORE-319:
----------------------------------------
SSLIOSession.handler is null. I'm using SSLNHttpClientConnectionFactory. I
have the BouncyCastle cipher suite at the head of the ciphers list. What else
would be relevant here?
I worked around the problem with the following hack:
--- C:\cygwin\tmp\t11240t143.tmp 2012-10-16 10:22:12.017333200 -0700
+++
c:\commander\ThirdParty\main\httpcomponents-core\httpcore-nio\src\main\java\org\apache\http\nio\reactor\ssl\SSLIOSession.java
2012-10-15 20:14:58.550000000 -0700
@@ -366,6 +366,8 @@
int bytesRead = receiveEncryptedData();
if (bytesRead == -1) {
this.endOfStream = true;
+ close();
+ return false;
}
doHandshake();
decryptData();
There may be a better way to handle this, but it does appear to resolve the cpu
loops when the server rejects a certificate.
> SSLIOSession goes into a loop if the server rejects an invalid certificate
> --------------------------------------------------------------------------
>
> Key: HTTPCORE-319
> URL: https://issues.apache.org/jira/browse/HTTPCORE-319
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Components: HttpCore NIO
> Affects Versions: 4.2.2
> Reporter: Scott Stanton
> Priority: Blocker
>
> To reproduce:
> * Set up an SSL server that requests certificates from the client.
> * Set up a client with an expired SSL certificate.
> * Establish a connection from the client to the server using BaseNIOReactor
> and SSLIOSession.
> The server will proceed through the handshake until the client supplies its
> certificate in response to the CertificateRequest message. At this point,
> the server's certificate verification will fail and it will close the
> connection.
> The client socket will become readable due to the EOF and the
> SSLIOSession.isAppInputReady() method is called to handle the EOF. The
> bytesRead gets set to -1, which sets this.endOfStream = true. Nothing ever
> sets the session into the CLOSING or CLOSED state, so it keeps looping on the
> readable EOF event.
> I'm not sure what the best approach to fixing this should be. It appears
> that if I close the session manually with the debugger from inside
> isAppInputReady, the system proceeds normally from that point, however I
> don't know what the implications of doing that might be.
--
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]
