Should the whole web *really* be encrypted? Isn't plaintext sometimes faster/better?

Question

It seems to be commonly accepted nowadays that all internet communication should be encrypted.
(For example, this is evident in how the HTTP 2.0 standard outright requires HTTPS.)

However, I have a hard time believing that this is the right way to go, but I feel I'm alone in this position.

Consider, for example, the download of large files (movies, application installers, etc.).
If the files are unencrypted, the same exact copy can be sent to multiple clients, allowing for better caching and network performance. (Of course this applies equally well to small files, but the motivation for large files is more apparent.)
Furthermore, this does not imply a security vulnerability: a server can send the file's cryptographic hash over HTTPS, but host the file itself over HTTP. The client can then easily check the hash of the file to verify its integrity.

Why is this approach undesired? Why should the entire web be encrypted, even when the communication content is itself clearly public knowledge and easily protected via a hash?

Answer 1

The additional overhead caused by the encrypting your payload is almost zero since CPUs today can encrypt at speeds of up to hundreds of MB/s. The only noticable delay is during connection setup, as you need a few additional round trips to set up SSL/TLS. However, if you are transferring large files, this round trip cost is negligible.

Yes, caching of unencrypted files will increase performance. However, there is a lack of privacy. The operator of the caching server can see the contents of your download since it is unencrypted. Therefore, the approach described above is not as common.

However, if you only need to verify integrity and have no need to maintain privacy, then the method above is fine.

Answer 2

There are some misconceptions or half-truth about HTTPS:

• Performance:
  • If you have lots of short connections it will be much slower because the main costs are in the initial key exchange and in the additional round-trips needed to establish the SSL connection on top of the TCP connection. The encryption itself is cheap, that is the more you transfer over the same connection the less signifikant the initial overhead will be.
  • Caching of data in middleboxes (proxies, firewall) will not be possible, but caching at the endpoint (browser) still works. This might not be a problem for most home users, but it is a problem for low-bandwidth or high-latency connections (satellite links) which often use caching proxies to optimize the connections. It will also be a problem with caching commonly used content (videos etc) at the ISP.
• Privacy:
  • HTTPS only protects against sniffing or manipulating the content. It does not hide the endpoints of the connection nor the traffic pattern nor DNS requests. For public content these information are usually enough to find out what sites the user is visiting and even which content on this site is viewed.
  • Additionally tracking by google-analytics and similar networks will still be done, so these tracking services still know enough about you, even if a lone attacker on the network will not. The same is true for advertising and social networks.
  • And while the Referer header is stripped when making a HTTP request from inside a HTTPS resource, it will still be sent cross-domain as long as both requests are HTTPS.
• Security:
  • HTTPS provides protection against sniffing or manipulating the content.
  • HTTPS does nothing to protect against current attacks like Cross Site Scripting, Cross Site Request Forgery, SQL Injection, Drive-By-Downloads or other kinds of malware downloads. But it will make it harder to detect such attacks within middleboxes. While SSL interception can be used in most cases, some applications like Dropbox use certificate pinning and don't make exceptions for user-added trust anchors like Chrome or Firefox do. This way these application can not be intercepted and thus must be either blocked or will pass through without inspection.
  • HTTPS protects against manipulation of the content, which does HTTP not. Even if one likes to cache public content the resistance against manipulation is a desired feature. The same is true for identification, i.e. it is a desired feature to verify the origin even of public content. But this is a feature which could provided without HTTPS, like by using the sites certificate to add a signature to the content.