Re: http/1 opportunistic encryption

Actually, #4 is also safe, you just don't get to do it and oppsec together.

On Fri, Jul 10, 2015 at 12:41 AM, Erik Nygren <erik@nygren.org> wrote:

> 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 <martin.thomson@gmail.com>
> wrote:
>
>> On 18 June 2015 at 01:26, Stefan Eissing <stefan.eissing@greenbytes.de>
>> 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.
>>
>>
>