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

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

On Mon, Mar 30, 2015 at 10:55 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

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