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

From: Jann Horn <[email-masked]>
Date: Sun, 29 Mar 2015 23:12:05 +0200

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.

Did I miss something, or is this a realistic attack against users of client
certificates (which, to be fair, probably is a really small set)?

If this is indeed a threat, these are the mitigations I can come up with:

 - Forbid the use of TLS Client Certificates for requests to HTTP
   Alternative Services.
 - Require the Alternative Service to opt-in using a new HTTP response
   header (similar to CORS response headers, whitelisting specific
   origins, or everything with *)

---

From: Patrick McManus <[email-masked]>
Date: Sun, 29 Mar 2015 20:55:28 -0400

I think its good advice not to send client certs here to avoid potential
murkiness. But I think there are several things in place that prevent it
from being an immediate problem. (I actually think they could play a role
in http:// over TLS in general, but the async opportunistic properties of
OE demand auth than can work via plaintext too).

The important reason I think we're ok is that a server that responds to a
query for http://host:port with the resource of https://host:port has a
bug. The scheme is an important part of the URI; h2 and spdy carry it
explicitly - it should not be inferred from the route. That's why firefox
doesn't do OE with http/1. Servers that get this wrong have exposures
beyond client certificates.

Second, its not just the URI that uses the origin instead of the
Alternative Service route, its the TLS stack too. The only thing really
changed is the route - and this has clear precedence when using things like
CONNECT tunnels. So for TLS that means SNI (which iirc does not have a port
number) but also things like the client cert lookup algorithm. So the
request for http://bank.com:80 should not find the cert associated with
https://bank.com:443 even if it is being routed over port 443.

Thanks for the note.

-P

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 30 Mar 2015 10:10:20 -0700

> effectively allowing the attacker to bypass the protocol part of SOP

Why is the origin on the client still http://bank.com/ when it is
deliberately making requests to https://bank.com:443/ ?

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.

....Roy

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 30 Mar 2015 20:26:22 +0300

> deliberately making requests to https://bank.com:443/ ?

Because ALT-SVC does not change origin, only transport.

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.
 
> because the browser needs to get new code from the same origin, just

Redirects change origin, ALT-SVC does not.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 12:48:19 -0500

> Because ALT-SVC does not change origin, only transport.

That was my answer to the concern: don't tie your authentication to
the transport, tie it to the origin.  That is, if you are requesting
resources for a given origin, then make sure that you have everything
you need for that origin, including server authentication,
confidentiality and integrity if it is https://.  Finally, don't send
cookies, authentication or other stuff to origins that don't deserve
them, regardless of what is actually being used to send packets.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 30 Mar 2015 10:55:12 -0700

> Because ALT-SVC does not change origin, only transport.

Then it is broken.

> 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.

....Roy

---

From: Roberto Peon <[email-masked]>
Date: Mon, 30 Mar 2015 13:15:01 -0700

I think the point of the alt-svc field is to declare that the new transport
and port are the same origin in this case.
-=R

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 30 Mar 2015 15:31:59 -0700

On Mar 30, 2015, at 1:15 PM, Roberto Peon wrote:

> I think the point of the alt-svc field is to declare that the new transport and port are the same origin in this case.

Well, then Alt-Svc is a security hole.  Creating a security hole just
to avoid one duplicate request (retrieving the alternative service
before doing subrequests) would completely abuse the point of switching
to a TLS connection for that service.

A simple principle is that no header field from the response origin
can be allowed to change the same-origin for that response.  Only a
field from the target can do that safely (e.g., CORS).

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 Mar 2015 13:58:41 +1100

Alt-Svc explicitly doesn’t change the origin.

> On 31 Mar 2015, at 9:31 am, Roy T. Fielding <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/