Re: [TLS] SNI and tickets and resumption

Brian Sniffen <bsniffen@akamai.com> Mon, 11 August 2014 04:02 UTC

Return-Path: <bsniffen@akamai.com>
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 2D3A81A02BD for <tls@ietfa.amsl.com>; Sun, 10 Aug 2014 21:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Level:
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CJdy_BFv-O8C for <tls@ietfa.amsl.com>; Sun, 10 Aug 2014 21:02:08 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 17C1F1A01B0 for <tls@ietf.org>; Sun, 10 Aug 2014 21:02:07 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D233548453; Mon, 11 Aug 2014 04:02:06 +0000 (GMT)
Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 4A620482E3; Mon, 11 Aug 2014 04:02:06 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 2F07998042; Mon, 11 Aug 2014 04:02:06 +0000 (GMT)
Received: from Tereva.local (172.19.42.82) by usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 11 Aug 2014 00:02:05 -0400
From: Brian Sniffen <bsniffen@akamai.com>
To: Martin Rex <mrex@sap.com>, "mrex@sap.com" <mrex@sap.com>
In-Reply-To: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp>
References: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp>
User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0)
Date: Mon, 11 Aug 2014 00:02:03 -0400
Message-ID: <m28umvy8qs.fsf@usma1mc-0csx92.kendall.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ba6LVCrON_N5K-2-dwQqgEi0LlY
Cc: Adam Langley <agl@imperialviolet.org>, "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] SNI and tickets and 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, 11 Aug 2014 04:02:11 -0000

> Essentially, whenever a full handshake would result in the use of the
> same server certificate as the resumption proposed by the client,
> my server will perform session resumption, and ingnore SNI mismatches.

So if a server has a giant SAN cert for `eff.org` and `nsa.gov`, and a
session with one is resumed to the other---that's unsurprising?  I don't
see a path all the way through to an attack, but it leads me to worry
about a web app and a web server interacting in this way.

At least for HTTP, the changing SNI will indicate a change of cookie and
same-origin context.  But RFC 6066 says:

   If there is a mismatch between the server name used by the client
   application and the server name of the credential chosen by the
   server, this mismatch will become apparent when the client
   application performs the server endpoint identification, at which
   point the client application will have to decide whether to proceed
   with the communication.

So maybe the client applications all carefully follow this tricky
advice.

On the other hand, RFC 6066 also says:

   A server that implements [SNI] MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session. 

It doesn't sound like your server quite does that?

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies