W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: :scheme, was: consensus on :query ?

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Fri, 25 Jul 2014 12:14:31 +1200
Message-ID: <53D1A167.7040002@treenet.co.nz>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC