Re: #73: Alt-Svc Elevation of Privilege

The Systems Ports range of 0-1023 is defined in rfc6335, although the
purpose there is not well-defined.

     Erik

On Tue, Jun 16, 2015 at 1:55 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> Is there a formal definition of privileged ports in an RFC already, or
> would we be codifying tradition here?
>
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Monday, June 15, 2015 5:53 PM
> To: Martin Thomson; Mike Bishop
> Cc: Patrick McManus; HTTP Working Group
> Subject: Re: #73: Alt-Svc Elevation of Privilege
>
> So, I think we're back to the suggestion that we require an alternative to
> be on a privileged port if the origin is on a privileged port.
>
> Thoughts?
>
>
> > On 9 Jun 2015, at 1:54 pm, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >
> > On 8 June 2015 at 17:51, Mark Nottingham <mnot@mnot.net> wrote:
> >> 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.
> >
> > This is already something we consider either a) safe, or b) a lost
> > cause.  Cross protocol attacks using HTTP are already trivially
> > mounted for requests that only use safe methods and header fields,
> > such as form submissions.  I believe that the assumption is that HTTP
> > is well-enough known and unlikely to create a sequence of packets that
> > would cause bad things to happen.
> >
> > However, this potentially increases that surface area by allowing
> > same-origin requests, with the additional control that implies.  I'm
> > not especially concerned by that though: and I'm not concerned about
> > h1 as much as I am with unsecured protocols.  ALPN in TLS provides a
> > pretty strong assurance that the server knows what it is doing.
> > Unsecured HTTP/1.1 might be exploitable if you have a particularly
> > stupid service...maybe.
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>