Re: #73: Alt-Svc Elevation of Privilege

I think that this is something that can be addressed by applying CORS,
or its model.  The point of CORS is to determine that a request target
is willing to accept the request (and in this situation, the attacker
is the one answering that question).

I think that the <1024 solution is hacky as hell, but better than
anything I can think of.

My alternatives:

. Require an HTTP/2 stack to strip Alt-Svc on the way out, unless it
is specially authorized.  That's predicated on h2 implementers seeing
this advice and it might already be too late for that.

. Insist on the header field being proposed by resources under /.well-known/.

The frame is superior in this sense; hosted resources won't be able to
insert those without authorization.

The /.well-known/ option might work as a means of breaking out of the
1024-port block.

On 8 June 2015 at 10:32, Patrick McManus <mcmanus@ducksong.com> wrote:
> yes, with usual caveat that the delay applies to async bg stuff and not qoe
> beyond opportunity cost.. so somewhat less impt.
>
> On Mon, Jun 8, 2015 at 11:59 AM, Ryan Hamilton <rch@google.com> wrote:
>>
>> FWIW, In the chromium implementation of Alternate-Protocol (and now
>> Alt-Svc) we require the new port to be < 1024 if the original port was <
>> 1024.
>>
>> Would CORS incur a latency penalty in these cases? Would we need to wait
>> for a CORS request to come back before we could use Alt-Svc?
>>
>> On Mon, Jun 8, 2015 at 6:11 AM, Patrick McManus <mcmanus@ducksong.com>
>> 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).
>>>
>>>
>>>
>>> On Sun, Jun 7, 2015 at 9:46 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>>>
>>>> <https://github.com/httpwg/http-extensions/issues/73>
>>>>
>>>> This issue asks if allowing a header to advertise an alternative on
>>>> another port (but still on the same host) is adequate, since in some shared
>>>> hosting environments, users will have the ability to add response headers,
>>>> as well as listen on other ports.
>>>>
>>>> Erik has suggested in the issue that it might be helpful to limit these
>>>> to privileged ports — i.e., those lower than 1024. I'm assuming such a
>>>> restriction would be in place if the origin port were also privileged.
>>>>
>>>> What do people think?
>>>>
>>>> --
>>>> Mark Nottingham   https://www.mnot.net/
>>>>
>>>>
>>>
>>
>

Received on Monday, 8 June 2015 17:52:43 UTC