Re: http/1 opportunistic encryption

> Am 20.07.2015 um 10:49 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
> 
> The canonical "serve different content" scenario is that http://example.com/path will serve redirects to https://example.com/path rather than actually returning the resource at /path....

Sure, 3xx and 4xx may happen for various reasons. 2xx responses should be scheme-invariant, ideally.

> 
> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] 
> Sent: Monday, July 20, 2015 10:36 AM
> To: Erik Nygren <erik@nygren.org>
> Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Ilari Liusvaara <ilari.liusvaara@elisanet.fi>; Amos Jeffries <squid3@treenet.co.nz>; ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>
> Subject: Re: http/1 opportunistic encryption
> 
> 
>> Am 20.07.2015 um 10:06 schrieb Erik Nygren <erik@nygren.org>:
>> 
>> This is helpful.  Since it sounds like both IIS/http.sys and Apache 
>> have http/2 implementations that effectively ignore :scheme by default 
>> and return https-scheme content when receiving :scheme=http over 
>> h2+TLS, I wouldn't be surprised if many other implementations ended up 
>> in the same boat.  I'm aware of one other implementation that started off doing this as well.
> 
> Well, as the one implementing http/2 in Apache, let me say that we do not "end" in this boat. We "start" in this boat because requirements and concepts of OE are new in http server configs. If existing servers treat port <=> scheme that seems a reasonable assumption *pre* OE.
> 
>> If implementations continue to do this, OE becomes just as 
>> problematic/risky over h2 as it is over http1.  Some options (perhaps in decreasing desirability?) seem to be:
> 
> Exactly the point I tried to raise here. Just waving the "h2" card for the code handling the ALPN callbacks will not make backend php application well behaved automatically.
> 
>> 1) Treat ignoring :scheme as a bug --- implementations should return (421 or?) in this case.
>>    Get implementations fixed and have this a recommended part of server interop tests
>>    and list as a common implementation bug.
> 
> I think this will not fly. Web servers do not control the applications they are running. For Apache to guarantee a well-behaved end-to-end OE implementation, it would need an "opt-in" 
> by the app processing the request. The best we could do would be to make the default "off"
> and let the server admin decide to where and when to turn it on. But he has that option already when she configures the Alt-Svc.
> 
>> 2) Only do OE over a new TLS ALPN identifier.  This has its own risks and defeats
>>     some of the purpose of OE.  On the other hand, it allows for actual explicit negotiation
>>     that the client/server supports OE which has other desirable properties.
> 
> Not helpful, IMHO.
> 
>> 3) Give up on worrying about http and https URIs being different and having different content.
>>     This would let us do OE over http/1.1 as well  (perhaps just add a "Scheme:" header under h1).
>>     There may be some attacks this opens up, and its pedantically incorrect.
> 
> I think it would be good for http: to be just the name for a variety of transports that are negotiated between clients and servers and each transport gives either the very same resource or is restricted to a only a subset, handing out 403 or 30x on unsuitable ones.
> 
> At least that would be my advise for anyone wanting to enable OE on his site - to not, now or in the future, serve different resources based on scheme. And if they do, they should not enable OE.
> 
> //Stefan
> 
>> On Tue, Jul 14, 2015 at 6:37 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
>> IIS/http.sys does this as well.  While requests in absolute form are supported, in the event that two different apps have registered listeners for the http://example.com:80/path and https://example.com:443/path resources, a connection on port 443 requesting http://example.com/path gets routed to the second application.  That hasn't changed in our HTTP/2 implementation.
>> 
>> Frankly, my inclination would be to 503 instead -- *neither* app has registered to serve http://example.com/path over port 443. But that's the legacy we have....
>> 
>> -----Original Message-----
>> From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi]
>> Sent: Monday, July 13, 2015 3:28 AM
>> To: Amos Jeffries
>> Cc: Erik Nygren; ietf-http-wg@w3.org Group
>> Subject: Re: http/1 opportunistic encryption
>> 
>> On Mon, Jul 13, 2015 at 10:07:01PM +1200, Amos Jeffries wrote:
>>> 
>>> If teh server is compliant with HTTP/1.1 it is expected to accept 
>>> absolute-URI not just relative-URI.
>>> 
>>> My understanding was that :scheme was supposed to be translated into 
>>> absolute-URI for the HTTP/1 server when the scheme does not match 
>>> the transport protocol used to the server. If it does match then 
>>> relative-URI was the right thing to do.
>>> 
>>> Whether reality matches that spec behaviour though is a good question.
>> 
>> Well, I have seen a server that when contacted over port 443 and then 
>> queried for http://example.org/ (using absolute-URI form) would 
>> interpret it as query for https://example.org/, and return different 
>> data from intended (expected site front page, got some test page with
>> 200 status).
>> 
>> It was running Apache with PHP (yuck) using FastCGI.
>> 
>> 
>> -Ilari
>> 
>> 
> 
> <green/>bytes GmbH
> Hafenweg 16, 48155 Münster, Germany
> Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
> 
> 
> 

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Received on Monday, 20 July 2015 08:53:20 UTC