Great foresight, Filip !
public int handshake(boolean read, boolean write) throws IOException {
if ( initHandshakeComplete ) return 0; //we have done our initial
handshake
...
}
+ no handling of the SSLEngineResult -> just perfect security !
I have an update to the unit test ( in case someone will accidentally
implement re-negotiation for
nio ), with the added timeout - test will be a bit slow.
We can update the message - if people use the NIO connector, they should be
safe for re-negotiation,
if they use the old connector they should either fetch the new release or
switch to NIO or APR
connectors ( APR if they upgraded their openssl ).
Costin
On Wed, Nov 11, 2009 at 10:29 AM, Filip Hanik - Dev Lists <
devli...@hanik.com> wrote:
> On 11/11/2009 11:13 AM, Costin Manolache wrote:
>
>> Sorry for my confusion - didn't realize NIO has its own ssl AND is not the
>> default in the embedded tomcat.
>> We should make it in trunk - and maybe get rid of the old connector, APR +
>>
>>
> the old connector is still the most stable one. So we should leave it in.
>
> NIO is enough ( plus the new one I'm
>> planning for lite :-)
>>
>> I changed the tests - the good news is that indeed NIO re-negotiation will
>> hung. I'm debugging why
>> and maybe make it close the connection - but it seems NIO connector is the
>> only safe one !
>>
>>
>
> it should hang, and probably eventually timeout and close the connection.
> Why, cause I can't remember coding it to allow renegotiation.
> But I will verify today.
> Filip
>
>
> We can tell people to switch to it while waiting for the other fixes...
>>
>> Costin
>>
>> On Wed, Nov 11, 2009 at 8:25 AM, Filip Hanik - Dev Lists<
>> devli...@hanik.com
>>
>>
>>> wrote:
>>>
>>>
>>
>>
>>> On 11/11/2009 12:11 AM, Costin Manolache wrote:
>>>
>>>
>>>
>>>> openssl s_client ...
>>>> Type "R" ( to renegotiate ).
>>>>
>>>> Unfortunately renegotiation is handled transparently and did work quite
>>>> well...
>>>>
>>>>
>>>>
>>>>
>>> bummer, I will see what needs to be done today.
>>>
>>> Costin
>>>
>>>
>>>> On Tue, Nov 10, 2009 at 10:53 PM, Filip Hanik - Dev Lists<
>>>> devli...@hanik.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I don't think NIO allows a renegotiation as it is today. I will have to
>>>>> look deeper in the code. But I think the negotiation is a one time deal
>>>>> per
>>>>> connection. I will look closer.
>>>>>
>>>>> Filip
>>>>>
>>>>>
>>>>> On 11/07/2009 09:59 AM, Mark Thomas wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> All,
>>>>>>
>>>>>> I was thinking about this on my way back from ApacheCon and we
>>>>>> probably
>>>>>> need to get some advice out to users early next week.
>>>>>>
>>>>>> My current understanding is that the MITM attack is triggered by a
>>>>>> renegotiation.
>>>>>>
>>>>>> On this basis I suggest something along the following lines:
>>>>>>
>>>>>> SSL using JSSE (BIO and NIO connectors)
>>>>>> - Don't use SSL configs that require renegotiation. i.e. SSL config
>>>>>> should be the same for the entire host. Sites that require SSL in some
>>>>>> places and SSL + CLIENT-CERT in others will require reconfiguration.
>>>>>> Sites that require SSL for some parts should be OK.
>>>>>> - Keep watch for a Sun update to the JDK that may help address the
>>>>>> issue
>>>>>>
>>>>>> SSL using tc Native
>>>>>> - tcnative does not support renegotiation
>>>>>> (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now
>>>>>> users of tc native with SSL should be OK
>>>>>>
>>>>>>
>>>>>> We also need to think about what to do with tc native. Maybe something
>>>>>> like:
>>>>>> - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is
>>>>>> disabled)
>>>>>> - keep an eye on httpd and if they find a work-around, copy it and
>>>>>> release 1.1.18 with renegotiation enabled
>>>>>>
>>>>>> For now, I'm not proposing any changes to the docs although we may
>>>>>> want
>>>>>> to put a summary of the advice - once agreed - on the security pages.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
