Doh! It seems like we've been fixing the same problem at the same time! On 7/31/07, James Gould <[EMAIL PROTECTED]> wrote: > > Trustin, > > We did some debugging and we created a version of SSLHandler that seems to > be working fine with renegotiation. I've attached the update SSLHandler > with the following changes and notes: > > > 1. Changed initialHandshakeComplete and initialHandshakeStatus > attributes to currentHandshakeComplete and currentHandshakeStatus, > respectively. This better reflects their purpose if renegotiation is > supported. I recommend changing the isInitialHandshakeComplete() method to > isCurrentHandshakeComplete(). I did not make the method change since it > would have changed the interface of the class. I actually have of question > of why these attributes are needed if the SSLEngine can be directly queried > for the values? > > I already made similar changes in the source code repository. SSLHandler has somewhat inefficient code, but we've retained it just to make sure not to break working code.
> 1. Added the firstHandshakeOfSessionCompleted attribute to ensure > that the SSLFilter.SESSION_SECURED event is only sent with the > initial SSL handshake. > > I made sure SESSION_SECURED is called for every successful handshake. I think it's more correct to fire it just once. Let me fix it. > 1. Set the currentHandshakeStatus to the > SSLEngineResult.getHandshake() value in the two places that the > renegotiation occurs. > 2. The currentHandshakeComplete (previously > initialHandshakeComplete) attribute is set to false at the beginning of the > handshake(NextFilter) method > > It's done on my side, too. :) > 1. Added a back the "while (!currentHandshakeComplete)" loop to the > handshake(NextFilter) method > > Could you explain a little bit more in detail? It seems like you are saying you just reflected variable rename. > 1. Set the currentHandshakeComplete and > firstHandshakeOfSessionCompleted attributes to true in the FINISHED case of > handshake(NextFilter) > > Looks good. > 1. Added a case for NOT_HANDSHAKING in the handshake(NextFilter) > method to get the existing unit tests to pass since the method threw an > exception when the handshake status became NOT_HANDSHAKING. We noticed > that > the handshake status went from NEED_UNWRAP immediately to NOT_HANDSHAKING. > How is the FINISHED handshake status skipped and when does the handshake > status change from FINISHED to NOT_HANDSHAKING? I set the > currentHandshakeComplete and firstHandshakeOfSessionCompleted attributes to > true in the NOT_HANDSHAKING just for insurance. > > It's interesting. My fix didn't cause this state at all. Could you please test with the latest subversion snapshot instead of your SSLHandler version? Let's see how it works differently. We ran through our initial set of tests and everything seems to work. > Review our updates and let me know if you make any updates to SSLHandler in > Subversion so that we can retest with the official version. > Currently, everything shold work fine except that it fires SESSION_SECURED more than once. Please apply some workaround meanwhile, and let me know how it works. Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
