On Wed, Nov 11, 2009 at 1:36 AM, Konstantin Kolinko
knst.koli...@gmail.comwrote:
2009/11/10 ma...@apache.org:
Author: markt
Date: Tue Nov 10 16:57:29 2009
New Revision: 834544
URL: http://svn.apache.org/viewvc?rev=834544view=rev
Log:
Proposal for cve-2009-3555 work-around
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
+
+* Disable TLS renegotiation be default with an option to re-enable it
+ Based on Costin's patch for trunk with Mark's modifications
+
http://people.apache.org/~markt/patches/2009-11-10-cve-2009-3555-tc6.patch
+ +1: markt
+ -1:
My understanding of the patch is that it disables any renegotiation,
either client-initiated or server-initiated, for connectors based on
JSSE.
Shouldn't there be an option to selectively enable server-initiated
renegotiation? E.g., to reset the listener if we are really expecting
a re-handshake, like JSSESupport class does with its handshake
listener in JSSESupport#handShake().
It could be done - but I guess the man in the middle could use the
server-initiated renegotiation. Server-initiated is only used for client
cert
auth - if the client doesn't send the cert on the initial handshake.
I would assume browsers will be patched as well soon, and may not
support re-negotiations the way they did.
Given the extra complexity and how big the whole is - I think we should
disable both until we have a better picture of the new SSL world.
Also, just a note, my understanding is that it won't help for Nio
connectors (those using the second constructor of JSSESupport class,
where there is session, but no socket). Those are ultimately based on
SecureNioChannel class and javax.net.ssl.SSLEngine.
Something else should be needed there.
Ops, I missed SecureNioChannel.
I'll try to submit a patch tonight, with SSLEngine you can cut the
negotiation earlier - but it's a bit trickier.
Maybe we can hold the release until we have this as well.
Costin
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
