You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2009/04/16 01:03:22 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Any way to fix bug 46950 without a change to tcnative?
Posted by Remy Maucherat <re...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Any way to fix bug 46950 without a change to tcnative?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Any way to fix bug 46950 without a change to tcnative?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Any way to fix bug 46950 without a change to tcnative?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org