Re: [TLS] SNI and tickets and resumption

Brian Sniffen <> Mon, 11 August 2014 04:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2D3A81A02BD for <>; Sun, 10 Aug 2014 21:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.669
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CJdy_BFv-O8C for <>; Sun, 10 Aug 2014 21:02:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 17C1F1A01B0 for <>; Sun, 10 Aug 2014 21:02:07 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id D233548453; Mon, 11 Aug 2014 04:02:06 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 4A620482E3; Mon, 11 Aug 2014 04:02:06 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 2F07998042; Mon, 11 Aug 2014 04:02:06 +0000 (GMT)
Received: from Tereva.local ( by ( with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 11 Aug 2014 00:02:05 -0400
From: Brian Sniffen <>
To: Martin Rex <>, "" <>
In-Reply-To: <>
References: <>
User-Agent: Notmuch/0.18.1 ( Emacs/24.3.1 (x86_64-apple-darwin12.4.0)
Date: Mon, 11 Aug 2014 00:02:03 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Adam Langley <>, " (" <>
Subject: Re: [TLS] SNI and tickets and resumption
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 `` and ``, 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

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 Sniffen
Information Security
Akamai Technologies