TLS in HTTP / 2

I wrote a review of “http2 explained” and made some presentations on HTTP / 2. After I received a lot of questions about the TLS and HTTP / 2 bundle, 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 tells you how to transmit TCP plaintext data, and how - through TLS.

In fact, TLS will always be used.

Despite the previous paragraph, the representatives of the developers of Firefox and Chrome announced that they will implement support for HTTP / 2 only through TLS. Therefore, HTTP / 2 will be supported only for URLs like HTTPS: //. IE developers said that they will implement TCP support, but in their technological preview, Windows 10 browser only supported HTTP / 2 via TLS. Most existing servers support HTTP / 2 via TLS
')
You need to understand the difference between what the specification permits and what is actually supported by browsers.

If you are developing a server for HTTP / 2, then, in general, you will have to implement it for HTTPS so that you have some users. A non-encrypted implementation will not be tested particularly hard ...

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

Stricter TLS implementation

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

Among other things, the specification requires ALPN support — a relatively new TLS extension, RFC 7301, which helps identify the new HTTP version without losing time or sending unnecessary packets.

Binding TLS encourages HTTPS

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

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

Why not make TLS mandatory?

When creating the specification, we did not reach agreement on the binding nature of this protocol. Many were against. Prior to this, TLS has never been 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, sometimes caching is necessary - you cannot make a decently working Internet on an airplane or via satellite, etc. without caching, which means no traffic interception.

Of course, the MITM proxies, which are embedded in SSL traffic, are still encountered, so HTTP / 2 can do little in terms of restricting such mechanisms.

2. Remember the kids

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

3. Certificates are expensive

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

4. CA system not working

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

Personally, I think that rejecting TLS because it is not perfect is a weak argument. We do not have the best ways to secure sites than TLS and HTTPS. I don’t mind improving these methods, but don’t do everything now via unprotected channels, until we come up with the next, better generation of protocols that will replace TLS.

What about opportunistic security?

In the IETF, work is now underway to introduce such an opportunity into the protocols. It was also included in the HTTP / 2 draft, although later we removed it from there for simplicity. In any case, it is not required to enter the main specification. In addition, not all consider this possibility a good idea.

Security is currently being developed for HTTP where possible beyond the HTTP / 2 specification whenever possible. It allows the client to upgrade the normal TCP connection to "unauthorized TLS". Yes, and of course, it is not necessary to designate such a connection as safe - no “lock icons” or other security indicator should be shown.

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