tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: SSL & Tomcat
Date Wed, 11 Nov 2009 18:39:59 GMT
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 <
devlists@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<
>> devlists@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<
>>>> devlists@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-unsubscribe@tomcat.apache.org
>>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message