- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Fri, 25 Jul 2014 12:14:31 +1200
- To: ietf-http-wg@w3.org
On 25/07/2014 6:53 a.m., Erik Nygren wrote: > I think the requirement is that http-scheme-over-TLS must only be done > in a way where the client and server agree on the scheme in a way that > works hop-by-hop and also works with legacy clients. In http/2 the > :scheme makes this clear. In prior versions (eg, http/1.1) it's not > clear there's a sane way (eg, new headers) that unaware intermediaries > can't be made confused by an adversary on the client or server side? Why would intermediaries be confused? http-scheme-over-TLS is only useful when communicating to an explicit proxy. So the request URI is required to be in absolute-form where the scheme: is explicitly sent as http:// regardess of the TLS connection it arrives on. FYI: Squid has been doing this for TLS between proxies and from supporting UA for over a decade with zero problems. If this restriction becomes a "MUST NOT" then you just made FastCGI, Perl, lynx, Chrome, Squid, curl, wget, and any number of other non-browser implementations non-compliant. The only confusion seems to be in certain browser implementers minds as a whole lot of FUD comes back for reasons not to implement every time the end users request better security on proxy connections. The only real technical problem I have heard in the whole debate is that changing the generic proxy config UI on Windows is a hard problem due to re-use. Amos > > On Thu, Jul 24, 2014 at 2:33 PM, Martin Thomson wrote: >> On 24 July 2014 11:21, Erik Nygren wrote: >>> I'd been under the assumption that http-scheme-over-TLS would only be >>> allowed over HTTP/2? >> >> I'll open that issue. We currently have no explicit restriction that >> prevents this. I don't think that we have any reason to say >> HTTP/2-only. I also don't think that we need a specific exclusion for >> HTTP/1.1, which is the other way we might cut this (so that we could >> retain the feature for some theorized HTTP/5, which may or may not be >> in active development for some major browser). >> >> That said, Mozilla doesn't plan to use oppsec for HTTP/1.1, at least >> in the short to medium term. >
Received on Friday, 25 July 2014 00:15:13 UTC