Re: [TLS] [oss-security] CVE-2009-3555 for TLS renegotiation MITM attacks
Marsh Ray <marsh@extendedsubset.com> Sat, 07 November 2009 16:23 UTC
Return-Path: <marsh@extendedsubset.com>
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 C822D3A6A0B for <tls@core3.amsl.com>; Sat, 7 Nov 2009 08:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.357
X-Spam-Level:
X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599]
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 HpKMd5fFpYw8 for <tls@core3.amsl.com>; Sat, 7 Nov 2009 08:23:58 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id F1A3C3A69AF for <tls@ietf.org>; Sat, 7 Nov 2009 08:23:57 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1N6o5O-000HKM-1K; Sat, 07 Nov 2009 16:24:22 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 81493667C; Sat, 7 Nov 2009 16:24:19 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/KW6//bAsn5H2LCv5RMTGF90eIU5ttlu8=
Message-ID: <4AF59F32.1030408@extendedsubset.com>
Date: Sat, 07 Nov 2009 10:24:18 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: rea-sec@codelabs.ru
References: <0911051520390.27904@mjc.redhat.com> <Fsm81lMN44X1vIl54+7dGMNZAWM@W35zwFHQJD9TSf5n3XGjbHLrnqQ>
In-Reply-To: <Fsm81lMN44X1vIl54+7dGMNZAWM@W35zwFHQJD9TSf5n3XGjbHLrnqQ>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: oss-security@lists.openwall.com, 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
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 16:23:58 -0000
Eygene Ryabinkin wrote: > > 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. Yes. I regret that we didn't get a chance to update the paper before making it generally available, so it is a bit understated: "Other techniques allow the attacker to forward or re-purpose client certificate authentication credentials." > 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? It's even worse than that. In practice, clients will sign with their client cert without user intervention. "For one thing, browsers' behavior of allowing automatic certificate sending is suspect and should be reconsidered. Secondly, browsers suffer from a fundamental inability to authenticate the specific transaction the server is about to execute, ostensibly on behalf of the client. That underlying problem should be addressed, and will likely involve either a protocol change or changes in the way existing protocols are implemented. "Finally, it may make sense to require clients to authenticate servers using the supplied certificate before handing client certificates back to the server. This will effectively prevent the chosen-server attack scenarios described above. This may also represent a breaking protocol change, however, and is being investigated. Even worse (and this is shown in some of the packet captures), web servers will execute MITM's request as soon as they get the Finished message from legit client, but the browser doesn't put up the scary page until he gets the Finished from the server (which could simply be silently dropped by the MITM). So if a client has useful client cert (or smart card) credentials, MITM can redirect a request to a server of his choosing that will accept them, use them to authenticate his arbitrary transaction, and the browser may never even show the scary cert error page. - Marsh
- Re: [TLS] [oss-security] CVE-2009-3555 for TLS re… Eygene Ryabinkin
- Re: [TLS] [oss-security] CVE-2009-3555 for TLS re… Marsh Ray
- Re: [TLS] [oss-security] CVE-2009-3555 for TLS re… Peter Gutmann
- Re: [TLS] [oss-security] CVE-2009-3555 for TLS re… ArkanoiD
- Re: [TLS] [oss-security] CVE-2009-3555 for TLS re… Marsh Ray