Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of jak-tomcat-dev@m.gmane.org
 designates 80.91.229.12 as permitted sender)
To: dev@tomcat.apache.org
From: "Bill Barker" <billwbarker@verizon.net>
Subject: Re: svn commit: r834289 -
 /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
Date: Tue, 10 Nov 2009 18:42:29 -0800
Lines: 127
Message-ID: <hdd89o$itf$1@ger.gmane.org>
References: <20091110010244.4F838238888F@eris.apache.org>
 <hdanrd$t65$1@ger.gmane.org>
 <96e4b5230911092036j4d9c51a1j480dbce4e6968d0b@mail.gmail.com>
Sender: news <news@ger.gmane.org>


"Costin Manolache" <costin@gmail.com> wrote in message 
news:96e4b5230911092036j4d9c51a1j480dbce4e6968d0b@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 <billwbarker@verizon.net> 
> wrote:
>
>>
>> <costin@apache.org> wrote in message
>> news:20091110010244.4F838238888F@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org