Re: 2 questions

> On Mar 28, 2015, at 5:43 PM, Glen <glen.84@gmail.com> wrote:
> 
> Hi,
> 
> I have 2 questions, if I may.
> 
> 1. What were the reasons for HTTP/2 not requiring TLS?
> 
> Is there a significant performance consideration, is it related to the cost of certificates (which is now fairly low or even free), or are there other technical reasons?
> 
> It would be nice if the web was just "secure by default", and I would have thought that now would be the right time to move in that direction.
> 
> Also, at least 2 of the major browser vendors have said that they won't be supporting HTTP/2 without TLS, so surely no one is going to want to run their website without it?

Right now, about a third of web requests use TLS. Clearly there is a constituency for the web in the clear, although there is a definite trend towards more TLS. If HTTP/2 is supposed to replace HTTP/1 entirely, it should support both. Two vendors said they would not support, one said they would. Using the UPGRADE mechanism, an in-the-clear website can support both HTTP/1 and HTTP/2.

As you say, it would be nice if the web was secure by default, but it is not up to you or me to force the web in that direction, or to withhold better performance in HTTP until they fit my definition of “nice”. This is the first rule of the Internet: you are so not in charge.

TLS has a significant cost in processing power, and there are a few cases where its use is inappropriate. Those cases can probably be served nicely by HTTP/1, but we aim to replace HTTP/1.

> 2. Are the BREACH and CRIME exploits still applicable, especially with regard to content (body) compression? If so, does that mean that it's not possible to compress content (with gzip, for example) and still maintain security?

CRIME was specific to retrieving cookie information by having a shared compressed state for resource name (which was under attacker control) and the cookie (which was constant).
HTTP/2 does not compress headers like that, so this is gone.

BEAST relies on content encryption, and on the attacker being able to inject stuff into the response, discovering pieces of static content such as CSRF tokens. There are ways to foil this attack that worked for HTTP/1, and they should apply similarly to HTTP/2. HTTP/2 itself does nothing to solve this.

HTH

Yoav

Received on Saturday, 28 March 2015 21:32:39 UTC