- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Tue, 16 Jun 2015 17:55:39 +0000
- To: Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>
- CC: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
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/
Received on Tuesday, 16 June 2015 17:56:11 UTC