From nobody Wed Mar 5 02:50:32 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9AC1A03C7 for ; Wed, 5 Mar 2014 02:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 EULhdfHkJHfz for ; Wed, 5 Mar 2014 02:50:22 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4131A03C4 for ; Wed, 5 Mar 2014 02:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18031; q=dns/txt; s=iport; t=1394016619; x=1395226219; h=from:to:subject:date:message-id:references:mime-version; bh=tpOuxx5lzzIOcliI1CL/pChC07AxMuXLgSkeMLchl0E=; b=TQhwug/Q4vEaIwdotyCVKnzARKNRLDkGlQtnU2i4sze81jdRRnug8YyP aBuc0dMvQxsZE7Dm2ftaegphafwfalyYeFKZdq1HAkCxa9pieP5eF+FQc d2qeVAxkusA3wyn0ll4Bay+qPAYqCTV3C5vb5xyiK6+c8B4dh8zhzupM+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8GAJ4AF1OtJXHA/2dsb2JhbABRCQGDBTtXqnaNOohbgRkWdIIlAQEBBAEBAWsbAgEZAwECKAcnCxQHAggCBBOHeQ3NWheNdkoNCgeDHoEUBJg9gTKQeYMtgio X-IronPort-AV: E=Sophos;i="4.97,592,1389744000"; d="scan'208,217";a="308254712" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 05 Mar 2014 10:50:18 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s25AoI0v000990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 10:50:18 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.247]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 04:50:18 -0600 From: "Joseph Salowey (jsalowey)" To: "emu@ietf.org" Thread-Topic: [TLS] MITM Attacks on Client Authentication after Resumption Thread-Index: AQHPOGCyMwvLIF45O0S80vyn0IwaCw== Date: Wed, 5 Mar 2014 10:50:17 +0000 Message-ID: <1F9FC965-4AE5-47FF-99E5-0A0FC3BA6342@cisco.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.206.225] Content-Type: multipart/alternative; boundary="_000_1F9FC9654AE547FF99E50A0FC3BA6342ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/emu/sZRRmQNbiGc18B9O5gh2aA78WCk Subject: [Emu] Fwd: [TLS] MITM Attacks on Client Authentication after Resumption X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 10:50:29 -0000 --_000_1F9FC9654AE547FF99E50A0FC3BA6342ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Some vulnerabilities have been found in TLS involving session resumption, c= hannel binding and renegotiation. There is more information at https://= secure-resumption.com. Begin forwarded message: From: Karthikeyan Bhargavan > Subject: [TLS] MITM Attacks on Client Authentication after Resumption Date: March 3, 2014 at 7:20:55 AM PST To: > We are going to present some new man-in-the-middle attacks on TLS applications in Tuesday=92s 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 [2] Scenario =3D=3D=3D=3D=3D=3D 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=92s 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I=92ll 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=92s and S=92s 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 dat= a) (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 sa= me, the RI extensions on both handshakes will be the same. - Both handshakes complete with new mutually-authenticated sessions and rec= ord 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 th= e 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D During Step 3, C has a connection on which it first received M=92s certificate and later S=92s 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 =3D 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 =3D PRF(pre_master_secret, "extended master secret", session_hash) [0..47]; We=92ve 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 [2] https://secure-resumption.com [3] RFC5746: Transport Layer Security Renegotiation Indication Extension [4] The Compound Authentication Binding Problem (draft-puthenkulam-eap-bind= ing-04) [5] RFC5929: Channel Bindings for TLS [6] RFC5705: Keying Material Exporters for Transport Layer Security _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_1F9FC9654AE547FF99E50A0FC3BA6342ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Some vulnerabilities have been found in TLS involving session resumption, c= hannel binding and renegotiation.    There is more information at=  https://secure-resumption.= com.   

Begin forwarded message:

From:= Karthikeyan Bhargavan = <karthikeyan.bhargavan= @inria.fr>
Subje= ct: [TLS] MITM Attacks on Cl= ient Authentication after Resumption
Date:= March 3, 2014 at 7:20:= 55 AM PST
To: <= /b><tls@ietf.org>

We are going to present some new man-in-the-middle attacks on TLS
applications in Tuesday=92s 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 [2]

Scenario
=3D=3D=3D=3D=3D=3D
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=92s 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I=92ll 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=92s and S=92s 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 s= ession id.
  (M knows the master secret and record keys since it participate= d 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 sa= me, 
  the RI extensions on both handshakes will be the same.
- Both handshakes complete with new mutually-authenticated sessions and rec= ord 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 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
During Step 3, C has a connection on which it first received M=92s
certificate and later S=92s 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-0= 0.txt

The key idea is that each full handshake is associated with a session
hash, computed as

session_h= ash =3D 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_se= cret =3D PRF(pre_master_secret, 
            &nb= sp;            =             &nb= sp;  "extended master secret", 
            &nb= sp;            =             &nb= sp;   session_hash) [0..47]; 

We=92ve 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
[2] https://secure-resumpti= on.com
[3] RFC5746: Transport Layer Security Renegotiation Indication Extension [4] The Compound Authentication Binding Problem (draft-puthenkulam-eap-bind= ing-04)
[5] RFC5929: Channel Bindings for TLS
[6] RFC5705: Keying Material Exporters for Transport Layer Security
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--_000_1F9FC9654AE547FF99E50A0FC3BA6342ciscocom_--