Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Sat, 8 Dec 2012 02:01:21 +0000 (UTC)
From: "Scott Stanton (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12611921.1350339339353.6816.1354932081106@arcas>
In-Reply-To: <JIRA.12611921.1350339339353@arcas>
References: <JIRA.12611921.1350339339353@arcas>
Subject: [jira] [Commented] (HTTPCORE-319) SSLIOSession goes into a loop if
 the server rejects an invalid certificate
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCORE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526975#comment-13526975 ] 

Scott Stanton commented on HTTPCORE-319:
----------------------------------------

Ok, good news.  I finally managed to reproduce the problem in the debugger with full logging.  See [session|^agent002.log] and [ssl|^ssl.log] files for full tracing.  The steps I took to reproduce the problem were as follows:

* set a breakpoint in SSLEngineImpl.java:491 on the return NEED_UNWRAP line
* establish a connection
* watch for the connection handshake to get to the CertificateRequest message so there is a lot of data in the buffers
* kill the other end of the connection

At this point the NHttpConnectionBase.close() method will take the first condition (outbuf.hasData()) and set the write event mask without closing the connection and then return to the event loop.  When it unwinds to the event loop, both the readable and writable flags are set causing the event loop to immediately wake up again due to the persistent EOF event.  The write buffer still has data in it, which continues to prevent the close, despite the fact that the receiving end is gone.  I think the intent is for the timeout to take care of this, but because of the persistently readable condition, the socket never has a chance to stay in the reactor long enough to time out.

I believe the fundamental problem is that the session is allowing the read flag to remain set after EOF.  If that were cleared, the socket timeout should eventually close the connection.
                
> 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
>            Assignee: Oleg Kalnichevski
>            Priority: Critical
>             Fix For: 4.3-alpha2
>
>         Attachments: bug.log, log
>
>
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org