"Costin Manolache" <cos...@gmail.com> wrote in message news:96e4b5230911092036j4d9c51a1j480dbce4e6968...@mail.gmail.com... > Right, need to invalidate as well. > > The request will not be executed - how can he continue the attack ? >
I've seen references where the attacker caches the original request and replays it on a different connection. But I admit that I haven't tried to write a program that simulates the attack. > On Mon, Nov 9, 2009 at 7:49 PM, Bill Barker <billwbar...@verizon.net> > wrote: > >> >> <cos...@apache.org> wrote in message >> news:20091110010244.4f8382388...@eris.apache.org... >> > Author: costin >> > Date: Tue Nov 10 01:02:43 2009 >> > New Revision: 834289 >> > >> > URL: http://svn.apache.org/viewvc?rev=834289&view=rev >> > Log: >> > Fix for the SSL midm - disable client re-negotiation, connection will >> > be >> > closed. >> > >> > >> > Modified: >> > >> > tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java >> > >> > Modified: >> > tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java >> > URL: >> > >> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java?rev=834289&r1=834288&r2=834289&view=diff >> > >> ============================================================================== >> > --- >> > tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java >> > (original) >> > +++ >> > tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java >> > Tue Nov 10 01:02:43 2009 >> > @@ -42,6 +42,8 @@ >> > import java.util.Vector; >> > >> > import javax.net.ssl.CertPathTrustManagerParameters; >> > +import javax.net.ssl.HandshakeCompletedEvent; >> > +import javax.net.ssl.HandshakeCompletedListener; >> > import javax.net.ssl.KeyManager; >> > import javax.net.ssl.KeyManagerFactory; >> > import javax.net.ssl.ManagerFactoryParameters; >> > @@ -93,6 +95,9 @@ >> > private static final int defaultSessionCacheSize = 0; >> > private static final int defaultSessionTimeout = 86400; >> > >> > + private static final boolean midmMode = >> > + >> > "true".equals(System.getProperty("enable_ssl_mitm_vulnerability")); >> > + >> > static org.apache.juli.logging.Log log = >> > >> > org.apache.juli.logging.LogFactory.getLog(JSSESocketFactory.class); >> > >> > @@ -154,12 +159,34 @@ >> > SSLSocket asock = null; >> > try { >> > asock = (SSLSocket)socket.accept(); >> > + if (!midmMode) { >> > + asock.addHandshakeCompletedListener( >> > + new DisableSslRenegotiation()); >> > + } >> > configureClientAuth(asock); >> > } catch (SSLException e){ >> > throw new SocketException("SSL handshake error" + >> e.toString()); >> > } >> > return asock; >> > } >> > + >> > + private static class DisableSslRenegotiation >> > + implements HandshakeCompletedListener { >> > + private volatile boolean completed = false; >> > + >> > + public void handshakeCompleted(HandshakeCompletedEvent event) >> > { >> > + if (completed) { >> > + try { >> > + log.warn("SSL renegotiation is disabled, closing >> > connection"); >> > + event.getSocket().close(); >> >> This is just a nuisance. The black-hat can simply reconnect and request >> to >> resume the session. At the very least, the session would need to be >> invalidated as well. But from what I've read, even this isn't a very >> effective mitigation tactic. Since we are notified after the handshake >> is >> done, the black-hat already has all the information she needs to continue >> the attack. >> >> > + } catch (IOException e) { >> > + // ignore >> > + } >> > + } >> > + completed = true; >> > + } >> > + } >> > + >> > >> > @Override >> > public void handshake(Socket sock) throws IOException { >> >> >> >> >> --------------------------------------------------------------------- >> 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
