TLS in HTTP / 2

I wrote a review of “http2 explained” and made some speeches about HTTP / 2. After I got a lot of questions about the connection between TLS and HTTP / 2, so I would like to answer some of them in this article.

TLS is optional

In the approved HTTP / 2 specification, which will soon become the official RFC, there is nothing about the mandatory use of TLS. On the contrary, it describes how you can transmit data in plain text TCP, and how - through TLS.

In fact, TLS will always be used

Despite the previous paragraph, representatives of Firefox and Chrome developers announced that they will only implement HTTP / 2 support through TLS. Therefore, HTTP / 2 will only be supported for URLs such as HTTPS: //. IE developers said that they will implement support over TCP, but in their technological preview of Windows 10, the browser only supported HTTP / 2 via TLS. Most existing servers support HTTP / 2 through TLS.

You need to understand the difference between what the specification allows and what is actually supported by browsers.

If you are developing a server for HTTP / 2, then, in general, you have to implement it for HTTPS so that you have some kind of users. And an implementation without encryption will not be especially hard tested ...

Of course, not only browsers can be agents, but their share will exceed all others.

Tighter TLS Implementation

When describing HTTP / 2 through TLS, the specification makes more stringent requirements than those made for HTTP 1.1 through TLS. For example, TLS must be at least version 1.2. The specification prohibits compression and re-generation. Determines the minimum possible key sizes. Simply put, HTTP / 2 will use a more secure version of TLS.

Among other things, ALPN support is mandatory in the specification - regarding the new TLS extension, RFC 7301, which helps determine the new version of HTTP without time loss or sending unnecessary packets.

TLS Binding Encourages HTTPS

Since browsers will only use HTTP / 2 through TLS, sites will have to accept users over HTTPS. This is a little pressure on site owners to start providing HTTPS. More people are switching to secure connections.

I believe that this is good and right - and so do everyone who cares about users and their privacy rights, and the right to avoid mass surveillance.

Why not make TLS mandatory?

When creating the specification, we did not reach an agreement on the subject of this protocol. Many were against it. Prior to this, TLS was never mandatory.

People explained their objections in different ways.

1. Possible need for traffic tracking

Some say that sometimes you need to track traffic. Prisons, schools, antivirus programs, copyright protection, legal requirements, etc. In addition, caching is sometimes necessary - you cannot make a decently working Internet in an airplane or via satellite, etc. without caching, which means without traffic interception.

Of course, MITM proxies that are embedded in SSL traffic are still found, so HTTP / 2 can do little to limit such mechanisms.

2. Remember the kids

"Miniature devices will not be able to cope with the additional burden of encryption." Either because of the load on the CPU, or because of the need to process a bunch of certificates, which also periodically become outdated.

3. Certificates are expensive

The cost of certificates has always been cited as an argument against TLS - even without regard to HTTP / 2. Now there are CAs that offer free or cheap certificates, and in the future, initiatives like letsencrypt.com will make life even easier.

4. CA system is not working

Today, TLS requires a public key infrastructure where there are organizations that sign certificates. As a result, browsers trust several hundred organizations. I don’t think everyone likes it, and that this is the best security solution. Some people think that this problem should be solved through DANE (DNSSEC), while others are working on patches like Certificate Transparency OCSP.

Personally, I think that rejecting TLS because it is not perfect is a weak argument. There are no better ways to secure sites than TLS and HTTPS. I am not opposed to improving these methods, but now do not do everything through insecure channels until we come up with the next, best generation of protocols that will replace TLS.

What about “opportunistic security”?

IETF is currently working on introducing this feature into the protocols. It was also included in the draft HTTP / 2, although then for simplicity we removed it from there. In any case, it is not required to be included in the main specification. In addition, not everyone considers this a good idea.

At the moment, if possible, security is being developed for HTTP outside the HTTP / 2 specification. It allows the client to upgrade a regular TCP connection to “unauthorized TLS”. Yes, and of course, it is not necessary to designate such a connection as safe - no “lock icon” or other security indicator should be shown.

Firefox will enable support for such connections for HTTP by default starting with version 37.