Re: http/1 opportunistic encryption

> Am 20.07.2015 um 10:06 schrieb Erik Nygren <>:
> 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.


> On Tue, Jul 14, 2015 at 6:37 PM, Mike Bishop <> 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 and resources, a connection on port 443 requesting 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 over port 443. But that's the legacy we have....
> -----Original Message-----
> From: Ilari Liusvaara []
> Sent: Monday, July 13, 2015 3:28 AM
> To: Amos Jeffries
> Cc: Erik Nygren; 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 (using absolute-URI form) would interpret it as query for, 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

Received on Monday, 20 July 2015 08:36:09 UTC