Cloudflare announced December 3rd, 2015 that it has enabled HTTP/2 for everyone. But does a faster internet to everyone come at a cost?
Cloudflare now provides HTTP/2 for everyone. HTTP/2 became official in May 2015. HTTP/2 more or less mandates that all traffic be encrypted. The law of unintended consequences rears its head here. The designers of the HTTP/2 protocol (RFC 7450 and 7451) already thought of the consequences but thought that a secure internet was worth it, while knowing that many would try to break it and violate everyone’s privacy.
All major browsers already support HTTP/2 – two of them (Firefox and Chrome) will only support it for HTTPS. Internet Explorer will drop SPDY support once HTTP/2 is adopted. That logically means that a number of web sites will decide to enable HTTPS in order to support HTTP/2 for the users of the two aforementioned browsers. HTTPS comes with an extra round trip at the beginning of the connection, but HTTP/2 saves a lot of them during the transfers so in the end if there are at least a few tens of objects to retrieve, it will still be an improvement.
But this will cause a new issue: migrating to HTTPS will mean that the caches that are operated in universities, enterprises, all mobile phone operators and many ISPs will not be used anymore. This will immediately have two impacts: the first one is that the traffic on the internet will increase. Alarmists used to say that the 40 TBps trans-Atlantic total capacity is almost saturated and hard to upgrade – we'll see if that's true. The second effect is that origin servers will get a significant traffic increase, which is good for ADC vendors as well as for CDNs which will get many new customers and increase their revenue. Sadly, in a number of poorly connected countries where client-side caches are critical to the survival of the internet, CDNs will not be able to help and the situation will get even worse. That's also the case for a number of mobile phone operators who can observe high cache hit ratios today.
"In a number of poorly connected countries where client-side caches are critical to the survival of the internet, CDNs will not be able to help and the situation will get even worse."
What will very likely happen to address these situations is that ISPs and mobile phone operators will start to propose a faster internet access to their customers in exchange for a root cert that they can happily install in their browser so that the operator can decipher SSL traffic on the fly and cache again. End users are already prepared to accept this because they don't care at all about their privacy when it comes to whatever they do with their smartphone, otherwise they would always close their apps and type a password to access their emails. And the next logical step is that mobile phones sold by these operators will already have the root cert pre-installed in order to save a complex operation from the end user.
And that will lead to an interesting situation. First, SSL offloading solution vendors will happily see their sales increase. But the counter part is that the chain of trust of the SSL/TLS model will definitely be broken in that there will be no way for the end user to know if his or her data were safe or not. This chain is extremely fragile already and is regularly being abused, but now it could become the norm not to trust SSL anymore when rogue CAs becomes mandatory to access the net.
Fortunately, a few solutions are being worked on. On the HTTP working group they're called "Trusted Proxies" or "GET http://", as a reference to what an HTTPS request through an explicit proxy could look like. They consist in letting the end user choose what can be deciphered and what cannot. That allows proxy operators to let some trusted sites pass through and to decipher/inspect/cache contents for all others. That also allows for a better internet experience for everyone, with better caching and better privacy at the same time. While it is uncertain if this will happen in 2016, whatever can be done to make this happen is vitally important.
>>Learn more about HTTP/2
