Re: Moving forward on improving HTTP's security

On 2013-11-14 09:01, William Chan wrote:
> Well, it should be no surprise that the Chromium project is still 
> planning
> on supporting HTTP/2 only over a secure channel (aka TLS unless 
> something
> better comes along...). So, that's (C).

Your choice. But thanks to your team for providing a new diriving force 
behind HTTPS-to-HTTP MITM gateways. It is causing a surprising amount of 
extra sales and consulting work over here. Forgive me for not repeating 
myself about the whys of that.


> 
> As to opportunistic encryption, we have mixed opinions on the team on 
> that.
> Mike, Tim, can you explain why you like (A)? Here are some concerns 
> I've
> heard on it:
> * The marginal security benefit of unauthenticated encryption is fairly
> marginal. Which adversary is this intended to defeat? It might defeat
> something like Firesheep for now, until tools like that get updated to 
> MITM
> as well. Does it shift the economics very much on passive pervasive
> monitoring? What wins do y'all foresee here?

I posit that the actual benefit of it is actually zero, or possibly 
negative once the encryption overhead costs in terms of CPU and key 
management are accounted for. DANE is helping a lot in some cases, but 
there are still overheads.

HTTP/1 has long been capable of transferring messages with encrypted 
bodies and even partially encrypted headers. The level of uptake on that 
is very low. The only reason I can see for that changing is if 
implementers are given no choice in the matter, and the comments about 
chunked on this old Node.js thread is a good indicator of how popular 
that will be.
   [1] https://groups.google.com/forum/#!topic/nodejs/su23ZpGxhIw


> * As for downsides, will people read too much into the marginal 
> security
> benefit and thus think that it's OK not to switch to HTTPS? If so, that
> would be terrible. It's hard to assess how large this risk is though. 
> Do
> you guys have thoughts here?

More likely they will look at the imbalanced cost/benefit and shy away 
from both HTTPS and HTTP/2.0 entirely.


Or is that the intention here? to offer alternatives that are so 
obviously unworkable that adopting TLS is seen as the best thing by 
comparison despite all its flaws?

Amos

Received on Wednesday, 13 November 2013 22:52:00 UTC