Re: [TLS] Inter-protocol attacks

Martin Thomson <> Mon, 11 August 2014 06:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 578961A030F for <>; Sun, 10 Aug 2014 23:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kNi0pdqHkH28 for <>; Sun, 10 Aug 2014 23:06:45 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CDA91A030E for <>; Sun, 10 Aug 2014 23:06:45 -0700 (PDT)
Received: by with SMTP id m15so7959505wgh.27 for <>; Sun, 10 Aug 2014 23:06:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6GxpX/E4ZIml19730QI2o19XjZxDbiqQGlJBI9H+bsg=; b=Ve5ulL+4+8X67j7k8+Ds0jQFNlJb6TLvWak/6OidFuCS3ucS5ApeICt+IQOl+eO71S BZ/lc/YAycnanVSliD1OO+8ZPVqovRKdlG/B5VJrbbpe2gyPkPCgwreg3FLKdOrVINXF w3PaVtW6TbQNG4Ry3yi+yiFi3foLfy3Eddt8H6KiHVoH9slFlGmWOZcTuEW6k8SJOZVH qGi8IDoaxhsD8VIiDfMHFIza8TqEA4UqwjEF0tsHFA2/8m6IFzGICKBZVnF0oDIcPsgv +PCipkmYZMUPfIH7TdNWYKiJ1TH1gHBcw/r26Vq07l2MkjtIgDjsP2DinIe9XfZUyUo5 sakA==
MIME-Version: 1.0
X-Received: by with SMTP id fu10mr23191376wib.47.1407737204015; Sun, 10 Aug 2014 23:06:44 -0700 (PDT)
Received: by with HTTP; Sun, 10 Aug 2014 23:06:43 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sun, 10 Aug 2014 23:06:43 -0700
Message-ID: <>
From: Martin Thomson <>
To: Antoine Delignat-Lavaud <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [TLS] Inter-protocol attacks
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 06:06:47 -0000

On 10 August 2014 06:20, Antoine Delignat-Lavaud
<> wrote:
> Chrome introduced a very significant change to the authentication model of
> TLS that went virtually unnoticed. In SPDY, the TLS client session cache is
> no longer indexed by domain and port, but instead by domain set, IP and
> port: in classic TLS, an established connection or session can only be
> reused for the same domain, whereas in SPDY, it can be reused for any domain
> in the certificate verified when the session was created, provided that it
> points to the same IP as the original connection. The DNS condition is
> obviously meaningless to a network attacker, which means that all security
> guarantees that were previously session-specific should now be considered
> certificate-specific.

The behaviour you describe isn't quite correct, because - I believe -
that it requires that the DNS resolve to the same IP (or that one of a
set of alternative values point there).  But that's not a particularly
important detail, DNS has never been a part of the security story for
https.  It's a big part of http, but we all know what you get there.

Either way, this behaviour has been discussed at some length and was
not found lacking in the SPDY/HTTP2 context.  Yes, HTTP/2 standardizes
this practice.  The poor handling of Host header fields in HTTP/1.1
means that it will probably never be advisable to do something like
this there.

As always, I caution that we have to be careful to distinguish between
attacks on implementations and attacks on standards.  I am aware that
there are bugs in implementations.  I'm also told that they are
somewhat difficult to exploit.