Re: [TLS] MITM Attacks on Client Authentication after Resumption
"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Mon, 03 March 2014 16:54 UTC
Return-Path: <Kenny.Paterson@rhul.ac.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDCE1A0229 for <tls@ietfa.amsl.com>; Mon, 3 Mar 2014 08:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level:
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYQAp4iOo0JJ for <tls@ietfa.amsl.com>; Mon, 3 Mar 2014 08:54:54 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id DFD5F1A02A4 for <tls@ietf.org>; Mon, 3 Mar 2014 08:54:53 -0800 (PST)
Received: from mail144-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Mon, 3 Mar 2014 16:54:50 +0000
Received: from mail144-tx2 (localhost [127.0.0.1]) by mail144-tx2-R.bigfish.com (Postfix) with ESMTP id BC83314015E; Mon, 3 Mar 2014 16:54:50 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT001.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: PS-23(zzbb2dI98dIc89bh1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL177df4h17326ah8275bh8275dh1de097h186068h1954cbhz2fh109h2a8h839h942he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h)
Received-SPF: pass (mail144-tx2: domain of rhul.ac.uk designates 157.56.249.149 as permitted sender) client-ip=157.56.249.149; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AM2PRD0311HT001.eurprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10019001)(6009001)(428001)(51704005)(479174003)(189002)(199002)(24454002)(66066001)(87266001)(94946001)(2656002)(16601075003)(77982001)(76796001)(95416001)(69226001)(4396001)(85306002)(59766001)(94316002)(50986001)(47976001)(74366001)(15395725003)(74876001)(76786001)(63696002)(74706001)(81542001)(81342001)(92566001)(56776001)(80976001)(65816001)(36756003)(47736001)(83072002)(19580405001)(83322001)(19580395003)(93136001)(93516002)(15202345003)(85852003)(87936001)(86362001)(81686001)(51856001)(92726001)(15975445006)(54356001)(46102001)(56816005)(90146001)(31966008)(74502001)(83506001)(54316002)(80022001)(53806001)(49866001)(95666003)(81816001)(76482001)(74662001)(47446002)(74482001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB030; H:DBXPR03MB383.eurprd03.prod.outlook.com; CLIP:157.140.35.7; FPR:F40FF1F4.A2FA5392.BDF75D8B.E99191.206FD; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail144-tx2 (localhost.localdomain [127.0.0.1]) by mail144-tx2 (MessageSwitch) id 1393865689301250_10785; Mon, 3 Mar 2014 16:54:49 +0000 (UTC)
Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.238]) by mail144-tx2.bigfish.com (Postfix) with ESMTP id 8FE2B2C0065; Mon, 3 Mar 2014 16:54:48 +0000 (UTC)
Received: from AM2PRD0311HT001.eurprd03.prod.outlook.com (157.56.249.149) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 3 Mar 2014 16:54:45 +0000
Received: from DBXPR03MB030.eurprd03.prod.outlook.com (10.242.145.146) by AM2PRD0311HT001.eurprd03.prod.outlook.com (10.255.162.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 3 Mar 2014 16:54:43 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB030.eurprd03.prod.outlook.com (10.242.145.146) with Microsoft SMTP Server (TLS) id 15.0.888.9; Mon, 3 Mar 2014 16:54:42 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0888.003; Mon, 3 Mar 2014 16:54:42 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Thread-Topic: [TLS] MITM Attacks on Client Authentication after Resumption
Thread-Index: AQHPNvQ8UESJIvYGkUWBabB9Ec6CVprPjbaAgAAEu4CAAAIoAA==
Date: Mon, 03 Mar 2014 16:54:41 +0000
Message-ID: <CF3A6389.1851B%kenny.paterson@rhul.ac.uk>
References: <BB2FE60E-A7CA-4EA7-BFC8-AB794EC6FF00@inria.fr> <CF3A5B04.184EE%kenny.paterson@rhul.ac.uk> <E3602DA5-B23A-444D-BBF7-CFE949953C92@inria.fr>
In-Reply-To: <E3602DA5-B23A-444D-BBF7-CFE949953C92@inria.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [157.140.35.7]
x-forefront-prvs: 0139052FDB
Content-Type: text/plain; charset="euc-kr"
Content-ID: <EC9ACAEA283F394AB25AB192B3F69B73@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/p7bpvLZpeDmEaKSApQdtAd0xWR4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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: Mon, 03 Mar 2014 16:54:58 -0000
Karthik, Sorry, I was just trying to clarify the impact of your attack for non-experts - the suggestion that it is a MITM attack might make some readers think that M ends up knowing the keys at the end of the attack. I totally agree that it's unclear as to what "bindings" should be assumed by the protocol participants at the end of step 3. As I said, and I'll reiterate - great work guys! Cheers Kenny On 03/03/2014 16:46, "Karthikeyan Bhargavan" <karthikeyan.bhargavan@inria.fr> wrote: > > > >Rather, an application running at C might end up using TLS-protected data >that was supplied by M in step 2 of the attack as if it came from S (or >vice-versa). This is a comparable attack to the original renegotiation >attack of Ray&Dispensa and Rex. > > > > >Yes, indeed, the impact of our renegotiation attack is comparable to the >2009 renegotiation attacks. >In fact, the setup of our attack is closer to Rex’s version than Ray’s >version: >http://www.ietf.org/mail-archive/web/tls/current/msg03928.html > > > >as far as I can see - for the 3rd step of the attack, it >seems that M just passes messages backwards and forwards and ends up NOT >knowing the keys shared by C and S. Any authentication protocol is >vulnerable to a "message passing" attack of this type in which the >adversary simply acts as a wire, and it's not considered an attack on such >protocols. > > > > >I would note that the renegotiation handshake we are speaking about is >not exactly a standalone authentication protocol. It is the second >handshake on a connection, with different client or server identity than >the first handshake. This leaves room for > confusion: should an implementation associate the connection to the >first set of principals or the second? > > > >Indeed, it's correct that C *is* connected to S and S *is* connected to C >after step 3! (not just that they "think" they are so-connected). > > > > >Kenny, you seem to suggest that only the second should be considered. >Common web browsers and HTTPS libraries only consider the first. It is >interesting to try and understand which is the right answer here. > > >-Karthik > > > > > >What matters here is how a server application running at S interprets data >that may have been sent under TLS protection in the first 2 steps in the >attack: it may assume it came from C when in fact it came from M. > >The more accurate description from Karthik's text is this: > >Step 3. (Renegotiation C-M-S) > > > >... >Both handshakes complete with new mutually-authenticated sessions and >record keys. >C now thinks it is connected to S and S thinks it is connected to C. >(M does not know the new record keys but its previous messages to S on >the same connection >may be treated as authenticated by C.) > > > > >Indeed, it's correct that C *is* connected to S and S *is* connected to C >after step 3! (not just that they "think" they are so-connected). > >Cheers > >Kenny > > >On 03/03/2014 15:20, "Karthikeyan Bhargavan" ><karthikeyan.bhargavan@inria.fr> wrote: > >We are going to present some new man-in-the-middle attacks on TLS >applications in Tuesday¹s working group meeting. These attacks were >found as part of our research on trying to prove cryptographic >security for a TLS implementation [1]. We presenting some of the >materials here to kick-start some discussion and get early comments on >our proposed countermeasure. Some people on the list already know of >these attacks but this is the first public disclosure. > >More details are at https://secure-resumption.com ><https://secure-resumption.com/> [2] > >Scenario >====== >Consider a client C that normally authenticates to a server S using a >client certificate. If C uses the same certificate to authenticate to >a malicious server M, then we show that M can use C¹s certificate to >authenticate its own connection to S. > >The attack relies on the combination of an initial RSA or DHE >handshake, followed by session resumption on a new connection, >followed by a client-authenticated renegotiation. During the first two >handshakes, C has a connection to M and M has a connection to >S. During the third handshake, M is able to authenticate as C to S and >as S to C. > >This server-based man-in-the-middle attack should normally have been >prevented by the Renegotiation Indication (RI) extension [3] but by >injecting session resumption between the two full handshakes, we are >able to bypass the renegotiation countermeasure. > >Triple Handshake Attack >================ >I¹ll briefly summarise the attack below for an initial RSA key >exchange. The webpage [2] has diagrams that will be easier to follow, >describes more attack variants, and provides some disclosure status. > >The attack proceeds in three steps: > >Step 1. (Initial Handshakes C-M, M-S) >- C connects to M and M connects to S, both handshakes use RSA. >- M forwards C¹s and S¹s client hellos to each other. >- M receives an encrypted PMS from C and reencrypts it towards S. >- Both handshakes complete with new sessions and record keys. > Both sessions have the same master secret, random nonces, and session id. > (M knows the master secret and record keys since it participated in both >handshakes) > >Step 2. (Session Resumption C-M, M-S) >- C resumes its session with M on a new connection. >- M resumes its session with S on a new connection. >- M forwards all the abbreviated handshake messages unchanged between C >and S. >- Note that the RI extensions on both handshakes are empty, > since it is the first handshake on the connection >- Both handshakes complete with new record keys (and reuse old sessions) > Both connections have the same record keys and handshake logs (verify >data) > (M still knows the record keys and can send messages in either >direction.) > >Step 3. (Renegotiation C-M-S) >- S requests M for renegotiation with client certificate. > M requests C for renegotiation with client certificate. >- M forwards all renegotiation messages unchanged between C and S >- Note that since the handshake logs in the preceding handshake were the >same, > the RI extensions on both handshakes will be the same. >- Both handshakes complete with new mutually-authenticated sessions and >record keys. > C now thinks it is connected to S and S thinks it is connected to C. > (M does not know the new record keys but its previous messages to S on >the same connection > may be treated as authenticated by C.) > >At the end of Step 3, S has an incoming connection on which it >initially received data from an anonymous client (M) and later >received data from an authenticated client (C). This breaks the >intended guarantees of the RI extension. > >Countermeasures >=========== >During Step 3, C has a connection on which it first received M¹s >certificate and later S¹s certificate. If C refuses to accept this >change of server identity, then it can prevent Step 3 of the >attack. Indeed, we recommend mainstream web browsers and HTTPS >libraries should systematically forbid the change of server identities >during renegotiation. > >However, already at the end of Step 2, a number of connection and >session parameters, such as the tls-unique channel binding for the two >connections are the same. So any application-level mechanism that >relies on the TLS master secret [4] or channel bindings [5] or exports >TLS keying material [6] is vulnerable to a similar man-in-the-middle >attack. > >We argue that the core vulnerability here is that the TLS master >secret is not bound to enough elements of the TLS session. We propose >a new TLS extension that binds the master secret to the hash of the >all relevant handshake messages in the initial handshake. > >The proposed draft is available at: >http://secure-resumption.com/draft-bhargavan-tls-session-hash-00.txt > >The key idea is that each full handshake is associated with a session >hash, computed as > >session_hash = Hash(handshake_messages) > >where handshake_messages consist of all messages up to and including >the ClientKeyExchange. The extended master secret computation enabled >by the extension is then computed as > >master_secret = PRF(pre_master_secret, > "extended master secret", > session_hash) [0..47]; > >We¹ve implemented this extension in OpenSSL without much difficulty. >Changing the master secret derivation may seem radical, but we believe >it is the main way to counter future attacks that may rely on the >session synchronization (step 1) that we exploit here. > >An alternative countermeasure would be an extension (along the lines >of [3]) that includes the session hash as defined above in the >ClientHello and ServerHello messages of the abbreviated >handshake. This would provide an explicit link between the resumption >handshake and its original full handshake, and hence prevent the >renegotiation attack described above. > >We welcome comments and suggestions. >-Karthik Bhargavan, Antoine Delignat-Lavaud, and Alfredo Pironti > >[1] http://mitls.org <http://mitls.org/> >[2] https://secure-resumption.com <https://secure-resumption.com/> >[3] RFC5746: Transport Layer Security Renegotiation Indication Extension >[4] The Compound Authentication Binding Problem >(draft-puthenkulam-eap-binding-04) >[5] RFC5929: Channel Bindings for TLS >[6] RFC5705: Keying Material Exporters for Transport Layer Security > > > > >
- [TLS] MITM Attacks on Client Authentication after… Karthikeyan Bhargavan
- Re: [TLS] MITM Attacks on Client Authentication a… Paterson, Kenny
- Re: [TLS] MITM Attacks on Client Authentication a… Dr Stephen Henson
- Re: [TLS] MITM Attacks on Client Authentication a… Karthikeyan Bhargavan
- Re: [TLS] MITM Attacks on Client Authentication a… Martin Thomson
- Re: [TLS] MITM Attacks on Client Authentication a… Paterson, Kenny
- Re: [TLS] MITM Attacks on Client Authentication a… Adam Langley
- Re: [TLS] MITM Attacks on Client Authentication a… Martin Rex
- Re: [TLS] MITM Attacks on Client Authentication a… Andrei Popov
- Re: [TLS] MITM Attacks on Client Authentication a… Watson Ladd
- Re: [TLS] MITM Attacks on Client Authentication a… Adam Langley
- Re: [TLS] MITM Attacks on Client Authentication a… Martin Rex
- Re: [TLS] MITM Attacks on Client Authentication a… Salz, Rich
- Re: [TLS] MITM Attacks on Client Authentication a… Watson Ladd
- Re: [TLS] MITM Attacks on Client Authentication a… Nico Williams
- Re: [TLS] MITM Attacks on Client Authentication a… Dr Stephen Henson
- Re: [TLS] MITM Attacks on Client Authentication a… Martin Thomson
- Re: [TLS] MITM Attacks on Client Authentication a… Dr Stephen Henson
- Re: [TLS] MITM Attacks on Client Authentication a… Adam Langley
- Re: [TLS] MITM Attacks on Client Authentication a… Martin Rex
- Re: [TLS] MITM Attacks on Client Authentication a… Daniel Kahn Gillmor
- Re: [TLS] MITM Attacks on Client Authentication a… Nico Williams
- Re: [TLS] MITM Attacks on Client Authentication a… Bodo Moeller
- Re: [TLS] MITM Attacks on Client Authentication a… Xuelei Fan
- Re: [TLS] MITM Attacks on Client Authentication a… Martin Rex
- Re: [TLS] MITM Attacks on Client Authentication a… Adam Langley
- Re: [TLS] MITM Attacks on Client Authentication a… Karthik Bhargavan
- Re: [TLS] MITM Attacks on Client Authentication a… Karthik Bhargavan
- Re: [TLS] MITM Attacks on Client Authentication a… Martin Rex
- Re: [TLS] MITM Attacks on Client Authentication a… Xuelei Fan
- Re: [TLS] MITM Attacks on Client Authentication a… Karthik Bhargavan
- Re: [TLS] MITM Attacks on Client Authentication a… Xuelei Fan
- Re: [TLS] MITM Attacks on Client Authentication a… Liz meeks