Why browsers don't support TLS without encryption and deprecate compression for public data

Question

These days we observes trend to use HTTP over TLS (HTTPS) for all communication. It recommend all weighty Internet service vendors and that claims to good practice. But TLS suite have 3 options for different purposes:

1. Certificate verification to ensure server authority.
2. Hash verification to ensure the HTTP package is not mangled by network equipment, Man-in-the-Middle, ISP, etc.
3. Encrypt data to hide it from reading for Man-in-the-Middle.

First two options makes sense for all type connection. But third makes sense only for sensitive data. Suppose user open public PR site or public library. What the sense add encryption overhead to that data? The same situation with TLS compression and regular HTTP compression in TLS channel. Compression deprecated due CRIME and BREACH attacks vulnerability of encrypted data and that may be used for public data.

In the same time common browsers don't support NULL encryption. You can ensure on ssllabs.com test

I checked Chrome/54.0.2840.100 and Firefox/49.0 and both don't support TLS_RSA_WITH_NULL_SHA or similar

Answer 1

• public data doesn't mean no expectation of privacy when reading it: "how to deal with AIDS" maybe a public page, but readers may wish privacy.
• If the website has cookies, they are probably not public data (auth cookies, obviously, but tracking cookies too for example)

Answer 2

Even if data is publicly available, you may not want people to know that you personally are downloading it. For example, you might not want your employer to see that you're looking at publicly posted job listings.

Answer 3

From your question I read that you agree that server authentication is important to make sure you connect to the right server. You also agree that tamper resistance using a HMAC is important. But you ask why we need encryption in all cases, i.e. even for publicly available data and you claim that because of this encryption we deprecated the use of compression (BREACH, CRIME...) for TLS traffic.

First, compression for data transferred using TLS is only deprecated if these data contain sensitive parts, like CSRF tokens or authentication cookies. If all data are publicly available anyway then there is no need to disable compression because there is nothing to attack using this side channel.

Second, the most expensive part with TLS both in terms of latency as in terms of CPU usage is the initial TLS handshake which includes the key exchange. The compression of the payload itself is not free but comparably cheap, especially when considering that you still want to compute some HMAC due to the requirement of tamper resistance and this means that the all payload must be processed anyway (usually in user space) and cannot directly sent from disk.
And given that encryption is comparably cheap one could argue that in this can one could just encrypt the content instead of using only a HMAC because it adds some privacy to the communication in a cheap way. And privacy can also be important if you just access public data because it makes monitoring and profiling of user behavior harder. You never know how these information will be used and if they might be used against you. So if you can hide these in an easy and cheap way you should do it.

Answer 4

This is only about support of null encrypted ciphersuites in browsers.

No browser supports null encryption ciphersuites by default. In some browsers (opera 12) it is possible to enable null enc ciphers (they are available, but disabled by default), firefox apparently also has had option to enable null enc ciphers, but that option has been removed. (https://superuser.com/questions/797343/make-browser-and-server-use-the-enull-ssl-tls-cipher).