On Wed, Nov 11, 2009 at 1:36 AM, Konstantin Kolinko <knst.koli...@gmail.com>wrote:
> 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=834544&view=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 > >
