Re: Any way to fix bug 46950 without a change to tcnative?
On Thu, 2009-04-16 at 11:38 +0100, Mark Thomas wrote: > Thanks for the confirmation. The request is already read and buffered. > We 'just' need to renegotiation to require an SSL cert. > > I'll try and take a look at this but I'll probably need some help with > the C code. First step will be to get tcnative building and I haven't > looked at that since I moved to 64-bit Windows. > > All good fun :) About the "eat the bytes" part, the code is the same between java.io and APR. See the ACTION_REQ_SSL_CERTIFICATE action and the use of the buffered filter. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Any way to fix bug 46950 without a change to tcnative?
William A. Rowe, Jr. wrote: > William A. Rowe, Jr. wrote: >> Mark Thomas wrote: >>> Folks, >>> >>> I have been looking at bug 46950 [1]. Everything is fine with the BIO >>> connector but with APR the renegotiation fails to trigger a request for >>> the user's certificate. I assume that this is because the socket is >>> still associated with an SSLContext where the SSLVerifyClient is >>> something other than "require". >>> >>> I can't see any obvious ways to fix this without either modifying the >>> native code or adding a new method to the native interface. Can anyone >>> see differently? Any pointers to a pure Java solution would be great. >> I'd expect this to be solved in tcnative, at least exposing the correct >> hooks. It's non-trivial, you might have a look at how mod_ssl handles >> renegotiation. > > I meant to add... > > tcnative or otherwise, it's critical to exhaust the client's transmission > prior to initiating the renegotiation sequence. Often this means slurping > the entire contents of the POST body prior to negotiating the client cert. Thanks for the confirmation. The request is already read and buffered. We 'just' need to renegotiation to require an SSL cert. I'll try and take a look at this but I'll probably need some help with the C code. First step will be to get tcnative building and I haven't looked at that since I moved to 64-bit Windows. All good fun :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Any way to fix bug 46950 without a change to tcnative?
William A. Rowe, Jr. wrote: > Mark Thomas wrote: >> Folks, >> >> I have been looking at bug 46950 [1]. Everything is fine with the BIO >> connector but with APR the renegotiation fails to trigger a request for >> the user's certificate. I assume that this is because the socket is >> still associated with an SSLContext where the SSLVerifyClient is >> something other than "require". >> >> I can't see any obvious ways to fix this without either modifying the >> native code or adding a new method to the native interface. Can anyone >> see differently? Any pointers to a pure Java solution would be great. > > I'd expect this to be solved in tcnative, at least exposing the correct > hooks. It's non-trivial, you might have a look at how mod_ssl handles > renegotiation. I meant to add... tcnative or otherwise, it's critical to exhaust the client's transmission prior to initiating the renegotiation sequence. Often this means slurping the entire contents of the POST body prior to negotiating the client cert. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Any way to fix bug 46950 without a change to tcnative?
Mark Thomas wrote: > Folks, > > I have been looking at bug 46950 [1]. Everything is fine with the BIO > connector but with APR the renegotiation fails to trigger a request for > the user's certificate. I assume that this is because the socket is > still associated with an SSLContext where the SSLVerifyClient is > something other than "require". > > I can't see any obvious ways to fix this without either modifying the > native code or adding a new method to the native interface. Can anyone > see differently? Any pointers to a pure Java solution would be great. I'd expect this to be solved in tcnative, at least exposing the correct hooks. It's non-trivial, you might have a look at how mod_ssl handles renegotiation. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Any way to fix bug 46950 without a change to tcnative?
Folks, I have been looking at bug 46950 [1]. Everything is fine with the BIO connector but with APR the renegotiation fails to trigger a request for the user's certificate. I assume that this is because the socket is still associated with an SSLContext where the SSLVerifyClient is something other than "require". I can't see any obvious ways to fix this without either modifying the native code or adding a new method to the native interface. Can anyone see differently? Any pointers to a pure Java solution would be great. Cheers, Mark [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=46950 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
