Re: HTTP/2 and Pervasive Monitoring

A number of comments on this topic based on some discussions
I've had over the past few weeks:


OppSec as deployment vehicle or for security
--------------------------------------------

Using http:// scheme URIs over TLS for HTTP/2 should be thought of as
firstly as a stop-gap deployment vehicle for HTTP/2 to get past broken
middle boxes without requiring application-side changes to immediately
move to https scheme.

The OppSec side-effects of this have a nice secondary benefit for
raising the bar to PM, but there are significant concerns that there
are enough active attacks already today that this may provide a
misleading false sense of security.

On a related note, even having the word "security" here has the risk
that people will misunderstand it to unfortunate results.  (I live in
fear of reading some marketing copy along the lines of "Opportunistic
Security adds extra bonus value because it takes full advantage of
Opportunities to give you even more security than you got previously
with that older 'Real Security'." --- or something similarly
misleading and scary.)


On transitions and fallbacks
----------------------------

While this OppSec model also makes it straight-forward for a large
hosting provider or CDN to immediately deploy HTTP/2 for
http-scheme-over-TLS without application changes or needing to manage
per-customer certificates, we don't have terribly good models here to
make a smoother transition.

Transitioning from OppSec unauthenticated http-over-TLS to HTTPS has a
reasonable story:  provision a real certificate, 301 redirect
to https, then start using HSTS or similar.

However we don't have a story in the current draft for transitioning
from OppSec unauthenticated http-over-TLS to authenticated http-over-TLS
in an operationally supportable manner.  When a server returns:

   Alt-Svc: "h2"=443

it has no idea whether or not the client is going to try and validate
the certificate and what it will do if it will fail.
One possibility would be to do something like:

   Alt-Svc: "h2"=443; validate=pkix

but this is sent over cleartext.  This could be useful,
however, such that if browsers are going to require cert
validation they could know NOT to follow the AltSvc if
that "validate=pkix" isn't present.

An unfortunate side-effect here is that active MitM
could easily strip out that text.

Another unfortunate side-effect of this Alt-Svc OppSec model in
general is that it has some of the same unfortunate incentives when
certificate validation fails as STARTTLS has within SMTP where many
clients fall back to using cleartext http/1.1 instead of unauthenticated
encryption.  Saying "let's not implement it" just ends up
in the same boat of using cleartext http/1.1 for people who
aren't motivated to make the jump to HTTPS.

The counter argument I've heard is that http/2 without OppSec will be
a forcing function to get people to move to HTTPS, but there are
enough barriers to universal HTTPS today (lack of universal SNI/IPv6
and cert provisioning challenges), that I'm still strongly of the
opinion that it is worth having this "OppSec" deployment vehicle
bridge for the next few years at least until we get universal SNI
adoption.


> http:/ can use TLS with *arbitrarily weak* crypto algorithms,
> and no authentication, and it is treated *exactly* like
> HTTP/1.1 plaintext by browsers.

For better or worse, the current drafts don't easily support this in a
way that doesn't introduce risk during transitions as the server
doesn't have a good indication of whether http or https scheme will be
used.  (Earlier Alt-Svc drafts contained an "h2t" ALPN token, but this
has subsequently been dropped.)  The cost for modern servers of
AES-GCM (or ChaCha20-Poly1305 once that is supported) is typically low
enough that there's no point in using something weaker.  Similarly,
it's not clear what one would use other than ECDHE that would be
worthwhile and cheaper for key exchange.  (Wearing my
*not-a-cryptographer* hat.)

Doing anonymous key exchange without a server cert might
be useful to bring down the cost, but then there would
need to be some client handshake signalling (in the cleartext
client_hello) that OppSec http-over-TLS is going to be used,
and this is something we've wanted to avoid so far.

> For that matter this is not even specific to HTTP/2 in any way, it
> could also be deployed for HTTP/1.1.

Only if there was a way to convey Scheme (http vs https) in a way that
worked reliably for existing HTTP/1.1 servers.

       Erik