tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: SSL & Tomcat
Date Sun, 08 Nov 2009 18:36:35 GMT
On 07.11.2009 17:59, 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.

Yes, client side initiated (AFAIK the client can decide to do this at
any time) and server initiated (most likely case is requiring client
certs for some parts of the content served by the host, or varying
cipher configuration on one site.

> 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.

Except for client initiated renegotiation :(

> - Keep watch for a Sun update to the JDK that may help address the issue

Plus other vendors.

> SSL using tc Native
> - tcnative does not support renegotiation
> ( so for now
> users of tc native with SSL should be OK

We need to test whether existing versions of Tomcat (with or without
tcnative) support client side initiated renegotiation. I can do it for
the tcnative case. The test (not a full MITM scenario but only a reneg
test) uses the openssl command s_client which can do reneg when typing "R".

My gut feeling says with tcnative we will support reneg and it will be
transparent to Tomcat. If that turns out to be true, we would need to
react w.r.t. tcnative (see below).

> 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)

Yes, disabling is fine for the moment, because it doesn't break existing
functionality. We should also add a comment about it in docs somewhere,
so that users building themselves using their OS supplied outdated
OpenSSL have been warned.

> - keep an eye on httpd and if they find a work-around, copy it and
> release 1.1.18 with renegotiation enabled


and making 1.1.18 a dependency for 6.0.21 and 5.5.whatever.

> 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.


In summary the aspects for tcnative based SSL are

A) how to optionally fully disable all reneg
   - OpenSSL 0.9.8l
     - Breaks some future configs, but maxes on security
     - Users need to update binary tcnative to 1.1.17
       or rebuild their older version against new OpenSSL
B) how to disable client initiated reneg
   - Try porting httpd fix to tcnative
     - Will need new tcnative
C) how to fix config, so that there's no server initiated reneg
   - Needed in Addition to B)
D) how to fix reneg code, so that server initiated reneg gets safe
   - Might need proposed SSL extension, so newer
     OpenSSL version and possibly changes to tcnative



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message