Re: #73: Alt-Svc Elevation of Privilege

On 8 Jun 2015, at 11:11 pm, Patrick McManus <> wrote:
> its not optimal, but I would consider some kind of CORS mechanism (or more likely, CORS :)) here as part of the alt-svc establishment.
> relatedly I've heard concerns about even cross host with the cert check in environments with broad alternates - and the feeling that this bypasses the spirit of CORS. (though I disagree on that count, I do understand it).

I don't see how a CORS-like mechanism would help *this* concern, which is that a local attacker with the ability to add HTTP response headers and listen on another port could hijack a server; if they're listening to the other port, the certainly can do the CORS dance.

It *would* help against an attack whereby someone can inject HTTP response headers, and they want to attack a service that they don't control. I think there are two variants of this:

a) The other port isn't speaking HTTP; i.e., we're doing a cross-protocol attack against something like SMTP. If we disallow h1 in this situation, I *suspect* this is a manageable concern — although I wouldn't be completely surprised if someone found an implementation of some protocol somewhere that was so forgiving that one could shove carefully-crafted H2 into it and get it to do something. If we aren't comfortable allowing this (even though it's same-host only), a potential remedy would be to establish a well-known port (or two) for cases when 80 and/or 443 get an alternative to the same host, instead of adding latency with a CORS-like dance.

b) the other port is speaking HTTP. If we disallow h1 in this situation, the implementation we're talking to would have to ignore the strong warnings in h2 to check the origin for every request, and would be vulnerable not only here but also to other attacks, presumably.

The common thread here is "don't use h1 with alternatives" — which is where we're already at. Am I missing something?

Mark Nottingham

Received on Tuesday, 9 June 2015 00:51:44 UTC