Re: [TLS] MITM Attacks on Client Authentication after Resumption
"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Mon, 03 March 2014 16:30 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 0108F1A010B for <tls@ietfa.amsl.com>; Mon, 3 Mar 2014 08:30:28 -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 SX3-4X6zrLPd for <tls@ietfa.amsl.com>; Mon, 3 Mar 2014 08:30:24 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 01B491A00BB for <tls@ietf.org>; Mon, 3 Mar 2014 08:30:23 -0800 (PST)
Received: from mail145-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE021.bigfish.com (10.236.130.84) with Microsoft SMTP Server id 14.1.225.22; Mon, 3 Mar 2014 16:30:21 +0000
Received: from mail145-co9 (localhost [127.0.0.1]) by mail145-co9-R.bigfish.com (Postfix) with ESMTP id DB084480453; Mon, 3 Mar 2014 16:30:20 +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: -2
X-BigFish: PS-2(zzbb2dI98dIzz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h177df4h17326ah8275bh8275dh1de097h186068h1954cbhz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h)
Received-SPF: pass (mail145-co9: 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)(479174003)(199002)(189002)(24454002)(74706001)(74876001)(93516002)(74366001)(76786001)(94946001)(53806001)(65816001)(56776001)(77982001)(66066001)(31966008)(47446002)(74482001)(54316002)(93136001)(81342001)(86362001)(81542001)(80022001)(54356001)(36756003)(95666003)(92726001)(63696002)(76482001)(15202345003)(76796001)(80976001)(59766001)(74662001)(46102001)(16601075003)(83506001)(51856001)(83322001)(74502001)(90146001)(69226001)(85852003)(85306002)(56816005)(87936001)(15975445006)(47736001)(19580405001)(83072002)(81816001)(4396001)(95416001)(81686001)(19580395003)(94316002)(92566001)(2656002)(49866001)(15395725003)(47976001)(50986001)(87266001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB031; H:DBXPR03MB383.eurprd03.prod.outlook.com; CLIP:157.140.35.7; FPR:F41CF0F4.A4FA5312.BDD75D8B.E99191.206C4; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail145-co9 (localhost.localdomain [127.0.0.1]) by mail145-co9 (MessageSwitch) id 1393864218402238_18255; Mon, 3 Mar 2014 16:30:18 +0000 (UTC)
Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.245]) by mail145-co9.bigfish.com (Postfix) with ESMTP id 5E162360095; Mon, 3 Mar 2014 16:30:18 +0000 (UTC)
Received: from AM2PRD0311HT001.eurprd03.prod.outlook.com (157.56.249.149) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 3 Mar 2014 16:30:16 +0000
Received: from DBXPR03MB031.eurprd03.prod.outlook.com (10.242.145.147) 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:30:05 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB031.eurprd03.prod.outlook.com (10.242.145.147) with Microsoft SMTP Server (TLS) id 15.0.888.9; Mon, 3 Mar 2014 16:30:04 +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:30:04 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] MITM Attacks on Client Authentication after Resumption
Thread-Index: AQHPNvQ8UESJIvYGkUWBabB9Ec6CVprPjbaA
Date: Mon, 03 Mar 2014 16:30:03 +0000
Message-ID: <CF3A5B04.184EE%kenny.paterson@rhul.ac.uk>
References: <BB2FE60E-A7CA-4EA7-BFC8-AB794EC6FF00@inria.fr>
In-Reply-To: <BB2FE60E-A7CA-4EA7-BFC8-AB794EC6FF00@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="iso-8859-1"
Content-ID: <914E2E79A6F07542AE1D49A2D75F9DB2@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
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/Ootpu87EllshNcioDYcWqPABsHY
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:30:28 -0000
Hi Great work, and much kudos to Karthik and the team for finding this attack, documenting it, and engaging in its responsible disclosure. I think it's important to highlight one issue in the high-level description given by Karthik, below. Although the 3-step attack is described as a "server-based man-in-the-middle attack", the attacking server M, at the very end of the attack after step 3, does NOT end up knowing the keys being used by the attacked client and server, C and S. 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. So the text in Karthik's message: > During the third handshake, M is able to authenticate as C to S and as S >to C is not correct, 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. 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