Re: [TLS] Inter-protocol attacks

Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr> Fri, 15 August 2014 12:37 UTC

Return-Path: <karthikeyan.bhargavan@inria.fr>
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 30A241A0A75 for <tls@ietfa.amsl.com>; Fri, 15 Aug 2014 05:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.617
X-Spam-Level:
X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 TTKsSSrsyavQ for <tls@ietfa.amsl.com>; Fri, 15 Aug 2014 05:37:03 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A5E1A0A71 for <tls@ietf.org>; Fri, 15 Aug 2014 05:37:02 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.01,870,1400018400"; d="asc'?scan'208,217";a="89451082"
Received: from pool-64-222-88-227.burl.east.myfairpoint.net (HELO [10.0.1.3]) ([64.222.88.227]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 15 Aug 2014 14:36:46 +0200
Content-Type: multipart/signed; boundary="Apple-Mail=_2C7D84A6-E005-4FE1-9561-D0CCC3EA57B5"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
In-Reply-To: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp>
Date: Fri, 15 Aug 2014 08:36:44 -0400
Message-Id: <515ACDD8-F8F6-4A75-9F5E-E0EC5DB15D35@inria.fr>
References: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O3PsDw7Bveb4H7yRmyT7sZ1dQzY
Cc: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Inter-protocol attacks
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: Fri, 15 Aug 2014 12:37:07 -0000

On 14 Aug 2014, at 21:56, Martin Rex <mrex@sap.com>; wrote:

> But I still fail to see how session resumption would aggravate
> any bogosities performed by applications as long as the servers
> certificates on both handshakes (resumption an full)
> will properly *PASS* the usual server endpoint identification checks,
> which is what has been asserted.

Perhaps an example scenario would be useful.

-----
Suppose a TLS server S uses a certificate C for domain D
and a TLS server S’ uses a certificate C’ for domain D’.
S and S’ share a session ticket encryption key K (or a session cache).
(Real-world example in Antoine’s talk: D=bugzilla.mozilla.org and D’=git.mozilla.org)
——
Connection 1:
C intends to connect to D and completes a full handshake with S.
S sends C a session ticket for encryption (encrypted under K)
——
Connection 2:
C resumes its session over a new connection using the session ticket.
The network attacker redirects the connection to S’.
S’ will accept the ticket (since it uses the same ticket encryption key K)
C and S’ complete the abbreviated handshake.
——
Result: C thinks it is (re-)connected to server S/domain D but it is connected to server S’/domain D’,
even though S and S’ *do not* serve the same certificate.
(A similar trace can be worked out for session caches shared between S and S’)
——

That this result is undesirable should not be in doubt (it leads to medium-level security exploits in deployed websites.)  At what level do we fix it seems more open to debate.

One may argue that:

(a) this is the application’s fault (at S’). It is fine for S and S’ to share ticket encryption keys (or session caches) but the application (e.g. HTTPS) must carefully disambiguate streams meant for S and S’ using some application-level information (e.g. Host header)

(b) using SNI during resumption should prevent this. S’ should refuse to resume a connection that has an SNI=D when it does not have a certificate that covers D.

(c) TLS session tickets/resumption are underspecified. Session tickets should also include the server_identity, that is the server certificate/hash/server name, not just the client_identity (see http://tools.ietf.org/html/rfc5077#section-4). Then, during resumption, the client should indicate the certificate/server name it wishes to connect to (e.g. via SNI) so that S’ can check that the resumed connection is for the same certificate/server name. 

I gather (from Adam’s and Rich's emails) that Google and Akamai do some version of (c). 
One may force HTTP web servers to do (a), but what about SMTP/IMAP/… servers that may not have a convenient “Host” header?
One may also say that servers should use different ticket encryption keys for each certificate/domain they serve, but this would probably vastly increase the number of full handshakes.
One may try to use SNI as in (b), but only after downgrade attacks have been eliminated.










Is the above (a) a failure of TLS session resumption or (b) a failure of the server implementation at S’ or (c) a failure of the HTTP level addressing




> 
> -Martin
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls