Re: http2 opportunistic security negotiation

[Erik Nygren <[e-mail]>]

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.
>>
>
>
>