Re: http/1 opportunistic encryption

[Erik Nygren <[e-mail]>]

Out of curiosity, how have current demuxer implementations been handling
and passing the :scheme along?  It may be that many implementations
are ending up in the same situation as http/1.1 here...

For example, how many:

1) Pass :scheme along in a proxyline or similar (eg, OOB channel), with
downstream app handling it properly
2) Pass :scheme along as a "Scheme" request header  (but in a way that is
spoofable and indistinguishable from a client request header)
3) Pass :scheme along as a ":scheme" request header (or some other invalid
HTTP/1.1 header)
4) Fail if :scheme is not "https"
5) Pass :scheme along in a proxyline or similar (eg, OOB channel), with
downstream app ignoring it
6) Drop :scheme entirely

Unfortunately, of these only #1 is actually safe.

As sad as it makes me (due to making interception easier),
I keep coming back to wondering if a separate alpn token would
be safer for h/2 oppsec.

       Erik




On Thu, Jun 18, 2015 at 1:06 PM, Martin Thomson <[e-mail]>
wrote:

> On 18 June 2015 at 01:26, Stefan Eissing <[e-mail]>
> wrote:
> > I think, as a consequence, I need to disable the Alt-Svc support for
> http: in mod_h2, since scheme information is not available to others living
> inside Apache httpd and the described http/1.1 exploit will work exactly
> the same with h2 involved.
>
> It depends on how Apache reports things as being "https" or not.  If
> you can avoid generating those signals or suppress them, then it
> should be OK.
>
> We can certainly improve the text.  Here's what I have:
>
> Some HTTP/1.1 implementations use ambient signals to determine if a
> request is for an `https`
> resource.  For example, implementations might look for TLS on the
> stack or a port number of 443.
> An implementation that supports opportunistically secured requests
> SHOULD suppress these signals if
> there is any potential for confusion.
>
>