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

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

On Sun, Mar 29, 2015 at 5:12 PM, Jann Horn <jann@thejh.net> 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.
>
> 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 *)
>