Hi James, Thanks for the hints. I've just checked in the test case and the fix for SSL renegotiation. It should somehow work now. Please let me know if it fixes your problem.
Trustin On 7/31/07, James Gould <[EMAIL PROTECTED]> wrote: > Trustin, > > My answers are below. > > > JG > > ------------------------------------------------------- > James F. Gould > Principal Software Engineer > VeriSign Naming Services > [EMAIL PROTECTED] > Direct: 703.948.3271 > Mobile: 703.628.7063 > > > 21345 Ridgetop Circle > LS2-2-1 > Dulles, VA 20166 > > Notice to Recipient: This e-mail contains confidential, proprietary and/or > Registry Sensitive information intended solely for the recipient and, thus > may not be retransmitted, reproduced or disclosed without the prior written > consent of VeriSign Naming and Directory Services. If you have received > this e-mail message in error, please notify the sender immediately by > telephone or reply e-mail and destroy the original message without making a > copy. Thank you. > > > > From: Trustin Lee <[EMAIL PROTECTED]> > > Date: Tue, 31 Jul 2007 01:00:20 +0900 > > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > Subject: Re: Endless Loop in SSLHandler.unwrap causing Mina Gateway to Hang > > > > On 7/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> I pulled the latest revision, but now it's not getting far past the initial > >> handshake. > >> It looks like the IoHandler. handshakeCompleted is getting called now > >> multiple > >> times. We modified our handshakeCompleted method to not throw an exception > >> if it's called multiple times, but it's failing to consistently process > >> inbound and > >> outbound packets. It seems like the handshakeCompleted is getting called > >> with > >> everyone inbound and outbound packet. We're debugging it now, but I > >> thought > >> I > >> would let you know what our progress is. Below is a snippet of the logs > >> that > >> shows that the handshakeCompleted method is called once with the log > >> containing " SSL Session established" and than called a second time > >> resulting > >> in an exception. These logs are obviously from the version that throws an > >> exception when the handshakeCompleted method is called more than once. > > > > A few questions for clarification: > > > > 1. Are you using SSLFilter.USE_NOTIFICATION attribute? > > Yes we use the USE_NOTIFICATION attribute and we call handshakeCompleted in > our IoHander from within the messageReceived(IoSession, Object) method when > the message is SSLFilter.SESSION_SECURED. We use the notification to grab > the common name out of the client certificate once the handshake is > completed. > > > > > 2. Do you mean handshakeCompleted is called for every I/O, or just > > when renegotiation occurs? > > > > The SSLFilter.SESSION_SECURED event is being inserted multiple times now. > It's being called twice at initial handshake and at least once more prior to > us getting some really odd results. We're seeing an XML validation error of > a packet that shouldn't be validated. We have two IoHandlers, once that is > SSL to the client and the other that is TCP to our Application Servers, > where the packet returned by the Application Server is for some reason > getting validated as if it were a packet from the client. > > > 3. What happens if you ignore subsequent handshakeCompleted calls? > > Does it work fine, or give another error? > > > > We did make this change and we're seeing a high number of calls into > SSLHandler.handshake(). > > > And.. it would be really nice if we can get debug level log file so we > > can see how SSLFilter and SSLHandler is working. > > We're still doing some debugging and I'll forward it on once I have > something that makes some sense. > > I believe that there might be an issue with the current purpose and use of > the SSLHandler.initialHandshakeStatus and > SSLHandler.initialHandshakeComplete attributes in the context of a > re-negotiation. If the SSLHandler.initialHandshakeComplete is true and the > handshake status is anything but NOT_HANDSHAKING, shouldn't the > SSLHandler.initialHandshakeComplete be reset to false and the > SSLHandler.initialHandshakeStatus be reset in preparation with a call to > handshake. The loop in handshake could be the same as it was for an initial > handshake as long as the attributes are reset. We going to play around with > the resetting of the attributes to see if it helps out and putting the > handshake method back to the way it was. > > > > > > > Thanks, > > Trustin > > -- > > what we call human nature is actually human habit > > -- > > http://gleamynode.net/ > > -- > > PGP Key ID: 0x0255ECA6 > > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
