Re: http2 opportunistic security negotiation

[Patrick McManus <[e-mail]>]

I guess what I meant, but didn't say, was I don't understand your assertion
that this needs to be handled at the TLS layer.

This is afterall a typo in the uri - and that's always a problem for
routing :)

There are lots of existing pure h1 sites that have working
http://example.com and an https://example.com that gives a cert warning and
then a broken website if you proceed. We can certainly do better than a
broken website using http level response codes 3xx or 4xx, and if the
possibility of a typo leading to a cert dialog is so painful I would
suggest a valid cert might be the right option for such a org.. the usual
reasons around why-not-https (3rd party content, referrer) really don't
apply strongly to responding to this particular transaction.

crazy?



On Tue, Feb 10, 2015 at 7:02 PM, Patrick McManus <[e-mail]>
wrote:

> What about 421 for https scheme or any h1 on 443?
> On Feb 10, 2015 6:14 PM, "Erik Nygren" <[e-mail]> wrote:
>
>> The two motivations for OE are to 1) help HTTP/2 deployment for
>> HTTP-scheme sites by getting around meddlesome middle-boxes, while 2) also
>> providing a tiny bit of protection against pervasive monitoring.  In both
>> cases, the closer the traffic is to HTTPS traffic (port 443) the more
>> likely it is to make it through and work without interference.  Both argue
>> for using port 443 with a handshake where at least the ClientHello is
>> indistinguishable between a true HTTPS request and an OE HTTP request.
>>
>> The "cleanest" solution would just be to give OE for HTTP/2 its own ALPN
>> token such that it is explicitly negotiated where you only send that token
>> in your ClientHello.  This would help for #1 but is not ideal for #2.  On
>> the other hand, there are some many attack vectors for #2 that it seems
>> more worthwhile to make sure #1 works well while raising the bar a little
>> for #2 where possible.
>>
>>        Erik
>>
>>
>> On Tue, Feb 10, 2015 at 5:47 PM, Patrick McManus <[e-mail]>
>> wrote:
>>
>>> I might be under-thinking this one.... but it occurs to me its possible
>>> to not put the tls version of the site on 443 if there is no https://
>>> version of the site.. oe doesn't require a particular port number and 443
>>> seems like the wrong choice if https:// isn't available. too simplistic?
>>>
>>> On Thu, Feb 5, 2015 at 10:08 AM, Erik Nygren <[e-mail]> wrote:
>>>
>>>> While digging further into server-side implementation details of the
>>>> current opportunistic security draft, we identified a user experience
>>>> problem.  In particular, for a site that has Virtual Hosts which are
>>>> HTTP-only (ie, there is no valid certificate for them), there is no way in
>>>> the current proposal to both support Opportunistic Security  (negotiate h2
>>>> for http scheme over TLS without a necessarily valid certificate) without
>>>> also giving users accidentally typing in https URIs a certificate mismatch
>>>> interstitial they'd be prompted to click through.
>>>>
>>>
>>>
>>>
>>
>>