As noted elsewhere, I removed the compression option from LibreSSL. The commit message of “decompress libssl” didn’t explain why. Here’s a longer rationale to expand upon “a simpler feature set overall”.

Let’s start with a classic application that wants to put some data into the cloud. It conceptually looks like this:

data > cloud

But this allows the underwater submarines to read our data, and we don’t want that. We have to refactor our code somewhat, adding an abstraction layer to either use classic read/write/send/recv interfaces, or whatever new API our TLS library imposes on us. But now our program does this:

data > encrypt > cloud

Hurray! We’re safe. Then a committee comes along and a new feature gets added, TLS compression. Now we have:

data > compress+encrypt > cloud

I argue that this composition of compression and encryption is not really a composition but more of a conglomeration, and inferior to a what a true composition would look like:

data > compress > encrypt > cloud

It’s true that this will require a few more changes to application code, but remember. We’ve already refactored the code to abstract the IO pipeline. Adding a new filter to the pipeline at this point should be pretty trivial. (And it is. I’ve written transparent compression filters in C++ and Lua, which compose well with encryption (and base64, etc.) filters. The first change is hard; the rest are all easy.)

Why should we care? Because sooner or later somebody is going to want this pipeline:

data > compress > cloud

That’s something people want. (It’s called http, if you reverse the direction of the arrows.) If we’ve doubled down on TLS as our compression layer, this means we need to support the None cipher. We don’t want that. People keep patching the None cipher into OpenSSH, for example, but it doesn’t come like that out of the box.

It’s funny to see how many times data can get compressed moving from one place to another. I might download a zip file (of png files!). The web server, if configured just wrong, can apply http compression to it. If it’s https, the TLS layer can compress it again. If I’m using an SSH tunnel, that can compress it. If it’s travelling over IPsec, it can get compressed again. It can get compressed again by IP compression. How many layers of compression do we really need?