W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 30 Mar 2015 10:55:12 -0700
Cc: Jann Horn <jann@thejh.net>, ietf-http-wg@w3.org
Message-Id: <156E435D-13EC-404A-909C-4E554280BA0C@gbiv.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
On Mar 30, 2015, at 10:26 AM, Ilari Liusvaara wrote:

> On Mon, Mar 30, 2015 at 10:10:20AM -0700, Roy T. Fielding wrote:
>> 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 https://bank.com/. There are no HSTS rules
>>> for bank.com.
>>> Alice browses to http://news.com, a website to which she does not need a TLS
>>> connection. Mallory injects the following HTML snippet into the response:
>>>   <iframe src="http://bank.com"></iframe>
>>> Alice's browser now requests http://bank.com. 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 bank.com via TLS, authenticating Alice using the
>>> non-origin-specific TLS client certificate. The server at https://bank.com
>>> grants access to the client based on the TLS Client Certificate and
>>> returns sensitive data, but the origin on the client is still http://bank.com,
>>> effectively allowing the attacker to bypass the protocol part of SOP
>>> restrictions on XHR.
>> Why is the origin on the client still http://bank.com/ when it is
>> deliberately making requests to https://bank.com:443/ ?
> Because ALT-SVC does not change origin, only transport.

Then it is broken.

> The requests are marked: The requests have :scheme=http, instead of
> normal :scheme=https. And this is the reason for HTTP/2 requirement for
> OE: One can't reliably mark such requests for HTTP/1.X.

The requests go to a different TCP port.  It is therefore a different
authority and a different origin.

Received on Monday, 30 March 2015 17:55:38 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:49 UTC