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

  • TLS uses MACs not CRCs or plain hashes to ensure integrity. CRCs are only suitable for detecting accidental corruption, not deliberate manipulation. Commented Nov 21, 2016 at 10:17
  • 5
    I might not want my ISP to know which wikipedia pages I view. Encryption is cheap, so why bother with disabling it? Commented Nov 21, 2016 at 10:20
  • The question is in which situation TLS without encryption gives something that TLS with encryption doesn't? Why would you want your data not being ecrypted?
    – Mr. E
    Commented Nov 21, 2016 at 13:32

4 Answers 4

  • 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)
  • In that case the TLS has lack endpoint protection. If endpoint domain about AIDS then we know the reader read about AIDS
    – slonma
    Commented Nov 21, 2016 at 11:47
  • @slonma The domain can be about medicine, or more general, and only the url about AIDS. And even if the domain is ABOUT AIDS, the url is probably more specific. But yes, if it was possible to hide the domain name, it will be better.
    – Tom
    Commented Nov 21, 2016 at 11:56
  • 1
    And to continue on that, data size might indicate which article from the website it is. Still, using HTTPS is good as it makes raises the bar quite a bit.
    – domen
    Commented Nov 21, 2016 at 12:25

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.

  • If you are using your work computer, there's a good chance they can see it anyway as you will be behind a proxy
    – ste-fu
    Commented Nov 21, 2016 at 10:34

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.


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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .