Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks

Eygene Ryabinkin <rea-sec@codelabs.ru> Fri, 06 November 2009 20:05 UTC

Return-Path: <rea-sec@codelabs.ru>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B84B3A67B6 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 12:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.804
X-Spam-Level: **
X-Spam-Status: No, score=2.804 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DATE_IN_FUTURE_03_06=0.274, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, J_CHICKENPOX_23=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_83=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYRo34pcF5fD for <tls@core3.amsl.com>; Fri, 6 Nov 2009 12:05:11 -0800 (PST)
Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by core3.amsl.com (Postfix) with ESMTP id C023D3A6809 for <tls@ietf.org>; Fri, 6 Nov 2009 12:05:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Date:From:To:Cc:Subject:Message-ID: Reply-To:References:MIME-Version:Content-Type:In-Reply-To: Sender; bh=hrmFHl2P0u6L/pQ8PoRaDy+2i4BcAzVqt/08vKsgi2U=; b=aFu6p iZniN467lFjWg2on6RutbGTg3hTJpoecAyyy4vgGkOUq6yXS3xt5ExcZyb3PhSp6 jwzJqdfqKB5FRjNV4bne1CuZfr3b6oY3bkup5xPP/+NLZAf1rzgDQMIj6j+vICA/ DpyQ/bLH4LP0l8im59YtrDv73J998VWHH5Ute1WEOnV9OWACnmbkvJ9Tv7/JC1K/ XZ+ilE0QDtCiO11IDcVt0f26/KnsXWaI7CAdgCwGeLm1s3U/rcW9tVdUsTLUcKba UfrSXxSKELU0Z8RAMjjRuwe1rQjpU1RJfoV07Q68co31tPrLtiNttcl5JWSoGDhB Y7/IeSsziyyYq0BlA==
Received: from phoenix.codelabs.ru (ppp83-237-105-99.pppoe.mtu-net.ru [83.237.105.99]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1N6V3n-000IH3-92; Fri, 06 Nov 2009 23:05:27 +0300
Date: Sat, 7 Nov 2009 02:05:31 +0300
From: Eygene Ryabinkin <rea-sec@codelabs.ru>
To: oss-security@lists.openwall.com
Message-ID: <Fsm81lMN44X1vIl54+7dGMNZAWM@W35zwFHQJD9TSf5n3XGjbHLrnqQ>
References: <0911051520390.27904@mjc.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0911051520390.27904@mjc.redhat.com>
Sender: rea-sec@codelabs.ru
X-Mailman-Approved-At: Sat, 07 Nov 2009 06:52:35 -0800
Cc: tls@ietf.org, "Steven M. Christey" <coley@linus.mitre.org>
Subject: Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: rea-sec@codelabs.ru
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Nov 2009 11:25:40 -0000

Sorry for jumping in, but I had missed the topic in the other lists,
so I am trying to ask here.  Also CC'ing tls@ietf.org -- sorry for
such cross-posting.

Thu, Nov 05, 2009 at 03:24:30PM +0000, Mark J Cox wrote:
> Marsh Ray of PhoneFactor has discovered a flaw in the TLS/SSL protocol
> related to the handling of the session renegotiations.  In certain
> circumstances this flaw could be used in MITM attacks, allowing an
> attacker to inject attacker-chosen plain text prefix into a secure
> session of the victim.

Had anyone considered the scenario when the server requires client
certificate from the beginning, but MITM possesses some other
credentials that will be good for authentication (but can be of no use
for authorization)?  In this case MITM can use this certificate to start
the splitting request, then initiate renegotiation and proxy client's
request through the established channel.  I see that Apache asks for the
certificate for the second renegotiation, as well as the OpenSSL's
s_server.  Here is the trace for s_server:
-----
$ openssl s_client -msg -key userkey.pem -cert usercert.pem -host somehost -port 8443 | grep -E '^(<<<|>>>)'
Enter pass phrase for userkey.pem:
>>> SSL 2.0 [length 0086], CLIENT-HELLO
<<< TLS 1.0 Handshake [length 004a], ServerHello
<<< TLS 1.0 Handshake [length 0b01], Certificate
depth=1 /C=RU/O=some/CN=CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
<<< TLS 1.0 Handshake [length 010d], ServerKeyExchange
<<< TLS 1.0 Handshake [length 0055], CertificateRequest
<<< TLS 1.0 Handshake [length 0004], ServerHelloDone
>>> TLS 1.0 Handshake [length 056a], Certificate
>>> TLS 1.0 Handshake [length 0046], ClientKeyExchange
>>> TLS 1.0 Handshake [length 0086], CertificateVerify
>>> TLS 1.0 ChangeCipherSpec [length 0001]
>>> TLS 1.0 Handshake [length 0010], Finished
<<< TLS 1.0 ChangeCipherSpec [length 0001]
<<< TLS 1.0 Handshake [length 0010], Finished
R
RENEGOTIATING
>>> TLS 1.0 Handshake [length 0063], ClientHello
<<< TLS 1.0 Handshake [length 0030], ServerHello
<<< TLS 1.0 Handshake [length 0b01], Certificate
depth=1 /C=RU/O=some/CN=CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
<<< TLS 1.0 Handshake [length 010d], ServerKeyExchange
<<< TLS 1.0 Handshake [length 0055], CertificateRequest
<<< TLS 1.0 Handshake [length 0004], ServerHelloDone
>>> TLS 1.0 Handshake [length 056a], Certificate
>>> TLS 1.0 Handshake [length 0046], ClientKeyExchange
>>> TLS 1.0 Handshake [length 0086], CertificateVerify
>>> TLS 1.0 ChangeCipherSpec [length 0001]
>>> TLS 1.0 Handshake [length 0010], Finished
<<< TLS 1.0 Handshake [length 060a]???
<<< TLS 1.0 ChangeCipherSpec [length 0001]
<<< TLS 1.0 Handshake [length 0010], Finished
-----
If the second certificate is used for the authorization and it is
allowed to have distinct certificates during the first and second
negotiations, then this could be the other way to trigger this attack
against the servers that are requiring certificates from the beginning.

Any thoughts?
-- 
Eygene