Re: SSL Tomcat
Good catch !
If the listener is called in a separate thread, as it seems from your
debugging - the attacker may have a small window
when he can still push data - and potentially get the request executed. I
guess the probability is extremely
small - but theoretically can be done.
I'll try it - the solution would be to not read any application data until
we know the handshake is completed, for
example a lock. For the NIO connector - still all fine, since re-negotiation
can't even start, I don't think
openssl has this problem either.
Costin
On Wed, Nov 18, 2009 at 5:59 AM, Luciana Moreira Sa de Souza Signed by -
PrivaSphere AG s...@privasphere.com wrote:
Hello,
I just added the patch created by Costin Manolache to prevent the MITM
attack during re-negotiations for JSSE to our platform. I performed some
tests and at first I found the solution quite elegant. Nevertheless, when I
did some debugging to verify if everything was really fine I noticed one
thing.
It seems that this is a asynchronous approach. When I put a breakpoint in
the following code the connection was not interrupted.
public void handshakeCompleted(HandshakeCompletedEvent event) {
if (completed) {
Even after executing the following code I could continue to navigate
through the website. It seems to me that for some reason the connection is
not interrupted if there is a certain delay on the execution of the code
bellow.
log.warn(SSL renegotiation is disabled, closing
connection);
event.getSession().invalidate();
event.getSocket().close();
It seems to me that the approach with the Listener is asynchronous but at
the same time this solution seems to require some synchrony to work
properly.
So my question to you is:
How safe this solution is if the server becomes overloaded and delays the
execution of the HandshakeCompletedListener?
FYI, I ported the patch to tomcat 5.5 which is the one we are currently
using in our platform. I don't know if this could change the time behaviour
of the patch.
Regards,
Luciana Moreira
Costin Manolache wrote:
Unless someone has a better solution - I'll submit the fix ( tonight ),
will
disable re-negotiation for
Jsse-mode.
I added a system property to allow people how don't care about this, IMO
by
default it should
be on.
Also got the test case to work - please let me know if it's acceptable to
commit it, it depends
on having a .keystore with a 'localhost' cert, didn't find any other SSL
tests in the suite.
Forgot that you need to read() after startHandshake() - just cutpasted
the
code from
JsseSupport and it worked.
--
This message has been signed by the PrivaSphere Mail Signature Service.
Re: SSL Tomcat
Hello, I am currently working on my company's platform to get around this security problem during re-negotiation. After discussing with my group about the progress being made towards a fix for tomcat, some questions were raised and I was hoping you could help me answer them. We use Tomcat 5.5 with JSSE installed via apt-get in the debian lenny distribution. Are there any plans of putting this fix as an update in the debian package? The other question is in relation to the configuration of this fix. I saw proposals of putting a property in the server.xml to prevent renegotiation from happening. Will this be done on a per Connector basis or will this be Server setting? I ask this since we have parts of the server were we would like to keep the old behavior and other parts that we have to completely stop re-negotiations. Thank you and best regards, Luciana Moreira Costin Manolache wrote: openssl s_client ... Type R ( to renegotiate ). Unfortunately renegotiation is handled transparently and did work quite well... 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 -- This message has been signed by the PrivaSphere Mail Signature Service. smime.p7s Description: S/MIME cryptographic signature
Re: SSL Tomcat
On 11/11/09 09:09, Luciana Moreira Sa de Souza Signed by - PrivaSphere AG wrote: Hello, I am currently working on my company's platform to get around this security problem during re-negotiation. After discussing with my group about the progress being made towards a fix for tomcat, some questions were raised and I was hoping you could help me answer them. We use Tomcat 5.5 with JSSE installed via apt-get in the debian lenny distribution. Are there any plans of putting this fix as an update in the debian package? It's up to debian maintainers weather they'll do that. The other question is in relation to the configuration of this fix. I saw proposals of putting a property in the server.xml to prevent renegotiation from happening. Will this be done on a per Connector basis or will this be Server setting? I ask this since we have parts of the server were we would like to keep the old behavior and other parts that we have to completely stop re-negotiations. Per Connector. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On Wed, Nov 11, 2009 at 12:09 AM, Luciana Moreira Sa de Souza Signed by - PrivaSphere AG s...@privasphere.com wrote: Hello, I am currently working on my company's platform to get around this security problem during re-negotiation. After discussing with my group about the progress being made towards a fix for tomcat, some questions were raised and I was hoping you could help me answer them. We use Tomcat 5.5 with JSSE installed via apt-get in the debian lenny distribution. Are there any plans of putting this fix as an update in the debian package? The other question is in relation to the configuration of this fix. I saw proposals of putting a property in the server.xml to prevent renegotiation from happening. Will this be done on a per Connector basis or will this be Server setting? I ask this since we have parts of the server were we would like to keep the old behavior and other parts that we have to completely stop re-negotiations. Noting that the patch disables handshake renegotiation by default and it's enabled per connector. i.e. opposite of your question. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
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
Re: SSL Tomcat
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 + 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 ! 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
Re: SSL Tomcat
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 Listsdevli...@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
Re: SSL Tomcat
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
Re: SSL Tomcat
On 10.11.2009 01:17, Mark Thomas wrote: Costin Manolache wrote: Unless someone has a better solution - I'll submit the fix ( tonight ), will disable re-negotiation for Jsse-mode. I added a system property to allow people how don't care about this, IMO by default it should be on. Sounds good. Any chance it could be a connector property rather than a system property? If you don't have a chance to do this I can always make that change (and do some testing) tomorrow. Also got the test case to work - please let me know if it's acceptable to commit it, it depends on having a .keystore with a 'localhost' cert, didn't find any other SSL tests in the suite. Add the keystore to svn as well. That way, the test should always work. Forgot that you need to read() after startHandshake() - just cutpasted the code from JsseSupport and it worked. +1 to everything - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
openssl s_client ... Type R ( to renegotiate ). Unfortunately renegotiation is handled transparently and did work quite well... 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
Re: SSL Tomcat
2009/11/7 Mark Thomas ma...@apache.org: We also need to think about what to do with tc native. Maybe something like: I think that we can - recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used our sources - for those architectures where binaries are available for 1.1.16 (windows 32/64-bit), rebuild them using OpenSSL 0.9.8l My understanding is that 1.1.17 and later require TC 6.0.21 and 5.5.29 and later and vice versa, because of some API changes, and thus won't be useful until those versions are released. - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is disabled) +1 - keep an eye on httpd and if they find a work-around, copy it and release 1.1.18 with renegotiation enabled +1 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 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On 09/11/09 11:34, Konstantin Kolinko wrote: 2009/11/7 Mark Thomasma...@apache.org: We also need to think about what to do with tc native. Maybe something like: I think that we can - recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used our sources - for those architectures where binaries are available for 1.1.16 (windows 32/64-bit), rebuild them using OpenSSL 0.9.8l Nope. Use 1.1.17 and 0.9.8l Just made binaries for 1.1.17 with APR 1.3.9 and OpenSSL 0.9.8l (Well, 64-bit versions are on the way) Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
Konstantin Kolinko wrote: 2009/11/7 Mark Thomas ma...@apache.org: We also need to think about what to do with tc native. Maybe something like: I think that we can - recommend recompiling 1.1.16 with OpenSSL 0.9.8l for those who used our sources - for those architectures where binaries are available for 1.1.16 (windows 32/64-bit), rebuild them using OpenSSL 0.9.8l My understanding is that 1.1.17 and later require TC 6.0.21 and 5.5.29 and later and vice versa, because of some API changes, and thus won't be useful until those versions are released. That isn't my understanding. 6.0.21/5.5.29 requires 1.1.17 but not the other way around (a method or two was added to the APR/native) libraries but nothing was removed. 1.1.17 should work happily with 6.0.x and 5.5.x Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On 09/11/09 11:56, Mark Thomas wrote: - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. I've uploaded binaries with APR-1.3.9/OpenSSL 9.8.8l. Should be visible within an hour. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
2009/11/9 Mark Thomas ma...@apache.org: Konstantin Kolinko wrote: My understanding is that 1.1.17 and later require TC 6.0.21 and 5.5.29 and later and vice versa, because of some API changes, and thus won't be useful until those versions are released. That isn't my understanding. 6.0.21/5.5.29 requires 1.1.17 but not the other way around (a method or two was added to the APR/native) libraries but nothing was removed. 1.1.17 should work happily with 6.0.x and 5.5.x I am glad to be wrong. I thought about the changes done by the following commit: http://svn.apache.org/viewvc?view=revisionrevision=832187 but those are already in 1.1.16 ..1.1.13. I have not looked earlier. So let's go with 1.1.17 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On 09.11.2009 11:56, Mark Thomas wrote: Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? +1, everything seems right to me and ready for notice to the users. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
2009/11/9 Mark Thomas ma...@apache.org: Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? Mark +1 s/negotiation/renegotiation/ s/port port/port/ A question: My understanding of renegotiation is that it changes SSL session. Is it possible to observe changes in the value of SSL sessionId? I doubt so, but may be? We read that value once and provide it to our users as javax.servlet.request.ssl_session request attribute. Regarding valves (as mentioned in issue 48157): I understand, that that is not sufficient, but if anyone wants to check against malformed headers, they can do so. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
Konstantin Kolinko wrote: 2009/11/9 Mark Thomas ma...@apache.org: Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? Mark +1 s/negotiation/renegotiation/ s/port port/port/ Noted. I'll get the notice out. A question: My understanding of renegotiation is that it changes SSL session. Is it possible to observe changes in the value of SSL sessionId? I doubt so, but may be? We read that value once and provide it to our users as javax.servlet.request.ssl_session request attribute. Hmm. Interesting. I need to do some testing :) I'll add something along the lines of We are currently evaluating a number of possible work-arounds prior to a protocol fix becoming available. Discussion is happening on the dev list and any significant developments will be posted to the users@ and announce@ mailing lists. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On 09.11.2009 17:16, Mark Thomas wrote: Konstantin Kolinko wrote: 2009/11/9 Mark Thomas ma...@apache.org: Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? Mark +1 s/negotiation/renegotiation/ s/port port/port/ Noted. I'll get the notice out. A question: My understanding of renegotiation is that it changes SSL session. Is it possible to observe changes in the value of SSL sessionId? I doubt so, but may be? We read that value once and provide it to our users as javax.servlet.request.ssl_session request attribute. Hmm. Interesting. I need to do some testing :) Yes, using the naive openssl test with s_client and the R command, the session id changes. In order to find out, whether this is optional behaviour or will always happen, I guess we would need to ask on the openssl dev list, which I will do in a minute :) I'll add something along the lines of We are currently evaluating a number of possible work-arounds prior to a protocol fix becoming available. Discussion is happening on the dev list and any significant developments will be posted to the users@ and announce@ mailing lists. +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2009/11/9 Mark Thomas ma...@apache.org: Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? Mark +1 s/negotiation/renegotiation/ s/port port/port/ A question: My understanding of renegotiation is that it changes SSL session. Is it possible to observe changes in the value of SSL sessionId? I doubt so, but may be? AFAIK you can reuse the session ID across negotiations ( it's a nice optimization BTW, too bad we're not using, it can speed up SSL connections a lot ), I'm not sure if it changes within a renegotation, but AFAIK when you start any negotiation you can specify you want to reuse the old session id. But if I understand the exploit correctly - they would want a different cypher, and if you reuse the session you reuse the old one. Maybe we can modify JSSESupport.Listener to break the connection if handshakeCompleted is called once in a connection ? That is besides disabling server-initiated handshakes. Costin We read that value once and provide it to our users as javax.servlet.request.ssl_session request attribute. Regarding valves (as mentioned in issue 48157): I understand, that that is not sufficient, but if anyone wants to check against malformed headers, they can do so. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache cos...@gmail.com wrote: On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2009/11/9 Mark Thomas ma...@apache.org: Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? Mark +1 s/negotiation/renegotiation/ s/port port/port/ A question: My understanding of renegotiation is that it changes SSL session. Is it possible to observe changes in the value of SSL sessionId? I doubt so, but may be? AFAIK you can reuse the session ID across negotiations ( it's a nice optimization BTW, too bad we're not using, it can speed up SSL connections a lot ), I'm not sure if it changes within a renegotation, but AFAIK when you start any negotiation you can specify you want to reuse the old session id. But if I understand the exploit correctly - they would want a different cypher, and if you reuse the session you reuse the old one. Maybe we can modify JSSESupport.Listener to break the connection if handshakeCompleted is called once in a connection ? That is besides disabling server-initiated handshakes. BTW - confirmed that JSSESupport.Listener is called when client does re-negotiate, but it is not called on the first negotiation ( it's added too late ). However it's pretty easy to add a listener earlier, patch attached - it should break all client re-negotiations, so we don't need to wait for a JDK fix. I wrote a small unit test - but I'm can't seem to get jsse client to re-negotiate for the test, can only do it using command line openssl. The patch seems to work - but you need so system properties or flags if we want to let people disable this ( allowManInTheMiddle is a good name for a flag ). Also the test needs a bit of work. If anyone has more time, my 20% is getting low Costin Costin We read that value once and provide it to our users as javax.servlet.request.ssl_session request attribute. Regarding valves (as mentioned in issue 48157): I understand, that that is not sufficient, but if anyone wants to check against malformed headers, they can do so. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the License); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and *
Re: SSL Tomcat
Unless someone has a better solution - I'll submit the fix ( tonight ), will disable re-negotiation for Jsse-mode. I added a system property to allow people how don't care about this, IMO by default it should be on. Also got the test case to work - please let me know if it's acceptable to commit it, it depends on having a .keystore with a 'localhost' cert, didn't find any other SSL tests in the suite. Forgot that you need to read() after startHandshake() - just cutpasted the code from JsseSupport and it worked. Costin On Mon, Nov 9, 2009 at 1:32 PM, Costin Manolache cos...@gmail.com wrote: On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache cos...@gmail.comwrote: On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2009/11/9 Mark Thomas ma...@apache.org: Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? Mark +1 s/negotiation/renegotiation/ s/port port/port/ A question: My understanding of renegotiation is that it changes SSL session. Is it possible to observe changes in the value of SSL sessionId? I doubt so, but may be? AFAIK you can reuse the session ID across negotiations ( it's a nice optimization BTW, too bad we're not using, it can speed up SSL connections a lot ), I'm not sure if it changes within a renegotation, but AFAIK when you start any negotiation you can specify you want to reuse the old session id. But if I understand the exploit correctly - they would want a different cypher, and if you reuse the session you reuse the old one. Maybe we can modify JSSESupport.Listener to break the connection if handshakeCompleted is called once in a connection ? That is besides disabling server-initiated handshakes. BTW - confirmed that JSSESupport.Listener is called when client does re-negotiate, but it is not called on the first negotiation ( it's added too late ). However it's pretty easy to add a listener earlier, patch attached - it should break all client re-negotiations, so we don't need to wait for a JDK fix. I wrote a small unit test - but I'm can't seem to get jsse client to re-negotiate for the test, can only do it using command line openssl. The patch seems to work - but you need so system properties or flags if we want to let people disable this ( allowManInTheMiddle is a good name for a flag ). Also the test needs a bit of work. If anyone has more time, my 20% is getting low Costin Costin We read that value once and provide it to our users as javax.servlet.request.ssl_session request attribute. Regarding valves (as mentioned in issue 48157): I understand, that that is not sufficient, but if anyone wants to check against malformed headers, they can do so. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
Costin Manolache wrote: Unless someone has a better solution - I'll submit the fix ( tonight ), will disable re-negotiation for Jsse-mode. I added a system property to allow people how don't care about this, IMO by default it should be on. Sounds good. Any chance it could be a connector property rather than a system property? If you don't have a chance to do this I can always make that change (and do some testing) tomorrow. Also got the test case to work - please let me know if it's acceptable to commit it, it depends on having a .keystore with a 'localhost' cert, didn't find any other SSL tests in the suite. Add the keystore to svn as well. That way, the test should always work. Forgot that you need to read() after startHandshake() - just cutpasted the code from JsseSupport and it worked. Mark Costin On Mon, Nov 9, 2009 at 1:32 PM, Costin Manolache cos...@gmail.com wrote: On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache cos...@gmail.comwrote: On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2009/11/9 Mark Thomas ma...@apache.org: Summarising the information gathered so far from various channels (thanks to Bill B., Bill W. Rainer who have done most of the actual work to find the info below). BIO/NIO connectors using JSSE. Vulnerable when renegotiation is triggered by the client or server. We could prevent server initiated renegotiation (and probably break the majority of configurations using CLIENT-CERT). We can't do anything to prevent client initiated renegotiation. APR/native connector using OpenSSL It is vulnerable when renegotiation is triggered by the client or by the server. Client triggered negotiation is supported. Server triggered negotiation will be supported from 1.1.17 onwards. OpenSSL 0.9.8l disables negotiation by default In terms of what this means for users: BIO/NIO - There isn't anything we can do in Tomcat to stop client initiated renegotiation so it is a case of waiting for the JVM vendors to respond. APR/native - Re-building their current version with 0.9.8l will protect users at the risk of breaking any configurations that require renegotiation. - We can release 1.1.17 with the binaries built with 0.9.8l. This will also protect users at the risk of breaking any configurations that require renegotiation. Mladen is doing this now. - Supporting renegotiation whilst avoiding the vulnerability will require a protocol fix. In the meantime, we could port port r833582 from httpd which would disable client triggered renegotiation for OpenSSL 0.9.8l (which may help some users who can't easily change their OpenSSl version and release 1.1.18 with this fix - Once the protocol is fixed, release 1.1.next bundled with the appropriate version of OpenSSL Have I got my facts right above? If so, any objections to posting the above to the users@ and announce@ lists along with adding something to the security pages? Mark +1 s/negotiation/renegotiation/ s/port port/port/ A question: My understanding of renegotiation is that it changes SSL session. Is it possible to observe changes in the value of SSL sessionId? I doubt so, but may be? AFAIK you can reuse the session ID across negotiations ( it's a nice optimization BTW, too bad we're not using, it can speed up SSL connections a lot ), I'm not sure if it changes within a renegotation, but AFAIK when you start any negotiation you can specify you want to reuse the old session id. But if I understand the exploit correctly - they would want a different cypher, and if you reuse the session you reuse the old one. Maybe we can modify JSSESupport.Listener to break the connection if handshakeCompleted is called once in a connection ? That is besides disabling server-initiated handshakes. BTW - confirmed that JSSESupport.Listener is called when client does re-negotiate, but it is not called on the first negotiation ( it's added too late ). However it's pretty easy to add a listener earlier, patch attached - it should break all client re-negotiations, so we don't need to wait for a JDK fix. I wrote a small unit test - but I'm can't seem to get jsse client to re-negotiate for the test, can only do it using command line openssl. The patch seems to work - but you need so system properties or flags if we want to let people disable this ( allowManInTheMiddle is a good name for a flag ). Also the test needs a bit of work. If anyone has more time, my 20% is getting low Costin Costin We read that value once and provide it to our users as javax.servlet.request.ssl_session request attribute. Regarding valves (as mentioned in issue 48157): I understand, that that is not sufficient, but if anyone wants to check against malformed headers, they can do so. Best regards, Konstantin Kolinko - To unsubscribe,
Re: SSL Tomcat
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 (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) 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 +1 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. +1 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 Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SSL Tomcat
On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas ma...@apache.org 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. IMO we could disable ACTION_REQ_SSL_CERTIFICATE ( with a flag allowManInMiddle or completely ). - Keep watch for a Sun update to the JDK that may help address the issue Or ask people to switch to tcNative ( i.e. openSSL ) or stop using client cert auth. 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? How about the cypher suites - I don't think we allow per-context config of allowed cyphers. Also not sure about client-initiated re-negotiation - I guess using a fixed openssl ( do they have a fix ? ) and native would avoid this, otherwise we need to wait for a jsse fix ? Costin
Re: SSL Tomcat
Mark Thomas ma...@apache.org wrote in message news:4af5a776.70...@apache.org... 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 IMHO, we will have to add an option to the Connector/ that allows the user to have the current renegotiation behavior. It can even print out an annoying warning in the log file if you set it. But without this option, what will happen is that users that are using CLIENT-CERT simply won't upgrade. And there a plenty of use cases where the user really isn't to worried about MITM. For example, if I am running an intranet server that uses CLIENT-CERT to identify employees, then if a black-hat can get in a position to exploit this, MITM is the least of my worries. 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 At the moment, https seems to be going for rejecting attempts by the client to renegotiate, but server renegotiation is unchanged (i.e. there is no configuration change necessary to force CLIENT-CERT for a specific directory). Perhaps tc-native could do something along the lines of r833582 (the httpd patch). 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
Re: SSL Tomcat
On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas ma...@apache.org 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 Also IBM, BEA, Apple etc. I'm not sure if JSSE is something Sun license to everyone, or if other JVMs have their own implementation (maybe OpenSSL based?). Harmony presumably does, though no idea if it's OpenSSL or clean room (couldn't see anything on a vague browse through their svn). 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 +1 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 Plus keeping an eye on the next openssl version for https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt ? Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
