Re: HTTP Alternative Services: What about TLS client certificates?

"Roy T. Fielding" <> Mon, 30 March 2015 17:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 85CD61A89F2 for <>; Mon, 30 Mar 2015 10:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DZTNF02T8vD3 for <>; Mon, 30 Mar 2015 10:14:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6FF31A89ED for <>; Mon, 30 Mar 2015 10:14:51 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1YcdCy-0003V0-16 for; Mon, 30 Mar 2015 17:10:40 +0000
Resent-Date: Mon, 30 Mar 2015 17:10:40 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.80) (envelope-from <>) id 1YcdCn-0003TQ-FQ for; Mon, 30 Mar 2015 17:10:29 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1YcdCm-0001g5-HY for; Mon, 30 Mar 2015 17:10:29 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 8426A2005D82E; Mon, 30 Mar 2015 10:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=wGdzQzXhZaLxo0Ik0OyZssOOocc=; b=DVenWM7c2Ylak0drRaXX9AniENK6 nTHsSqaUPwQ0I6CdN90HMpyThu4G7fRvmbLbk8xuIMTl6VOB7taeFnM5o8q+GdIo opp2GTd2Yqf4T/RbmgHARuFXmkFpQbwQH1JrEO/Lp2j2dhnGu2EXROqyodOHdkRD 5VoA3Cgxi3WvKEA=
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id AE9D32005E61A; Mon, 30 Mar 2015 10:10:05 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Mon, 30 Mar 2015 10:10:20 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Jann Horn <>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.8
X-W3C-Hub-Spam-Report: AWL=1.194, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1YcdCm-0001g5-HY 835b706a50a396ab050f5da8b5246ef2
Subject: Re: HTTP Alternative Services: What about TLS client certificates?
Archived-At: <>
X-Mailing-List: <> archive/latest/29077
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Mar 29, 2015, at 2:12 PM, Jann Horn wrote:

> Hello,
> I've looked through draft-ietf-httpbis-alt-svc-04 and didn't see anything that
> explicitly forbids the use of TLS client certificates. The threat scenario I
> have in mind is this:
> Alice is connected to the internet through a connection on which Mallory
> performs a MITM attack. Alice has a TLS client certificate that grants her
> access to sensitive information at There are no HSTS rules
> for
> Alice browses to, a website to which she does not need a TLS
> connection. Mallory injects the following HTML snippet into the response:
>    <iframe src=""></iframe>
> Alice's browser now requests Mallory intercepts the request
> and replies with a page containing malicious JavaScript code and the HTTP
> header 'Alt-Svc: h2=":443"'.
> The malicious JavaScript code now triggers further requests that the browser
> performs to via TLS, authenticating Alice using the
> non-origin-specific TLS client certificate. The server at
> grants access to the client based on the TLS Client Certificate and
> returns sensitive data, but the origin on the client is still,
> effectively allowing the attacker to bypass the protocol part of SOP
> restrictions on XHR.

Why is the origin on the client still when it is
deliberately making requests to ?

The client isn't being fooled into making those requests -- it is
choosing to make use of the Alt-Svc information to go to a different
origin.  In short, the JavaScript code should be prevented at that point
because the browser needs to get new code from the same origin, just
like a redirect.