Re: SSL compression

On Mon, Nov 8, 2021 at 10:11 AM Michael J. Baars <
mjbaars1977(dot)pgsql(dot)hackers(at)gmail(dot)com> wrote:

> On Mon, 2021-11-08 at 13:30 +0530, Abhijit Menon-Sen wrote:
> > At 2021-11-08 08:41:42 +0100, mjbaars1977(dot)pgsql(dot)hackers(at)gmail(dot)com wrote:
> > > Could someone please explain to me, why compression is being
> > > considered unsafe / insecure?
> >
> > https://en.wikipedia.org/wiki/CRIME
> >
>
> Well Abhijit, personally I don't see any connection between crime and
> compression. I do see however, that some people might feel safer
> communicating over an SSL
> ENCRYPTED line doing their daily business, unjustified as that is, but
> they shouldn't be feeling safer communicating over a compressed line, that
> would be
> utterly stupid.
>

This is talking about the CRIME attack which *explicitly* is about using
the fact that it's the *combination* of encryption and compression that
causes a problem. There are other similar attacks as well. If you read the
link posted, it will give you a pretty decent overview.

The sole purpose of compression is to reduce the size of a particular
> amount of data.

This part is of course correct. The problem lies in the *interaction* of
compression and encryption. This is why doing compression as part of the
encryption layer is fundamentally wrong.

The problem is that to make it secure, you have to encrypt first and then
compress. But encryption makes the compression a *lot* less efficient, so
what most solutions did was compress first and then encrypt, which led to
vulnerabilities.

Would it be good to have the ability to do compression, independent of the
encryption? Yes, definitely. But this is not a feature that PostgreSQL has,
or ever had.

> > Might the underlying reason be, that certain people have shown
> > > interest in my libpq/PQblockwrite algorithms (
> > >
> https://www.postgresql.org/message-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel%40cyberfiber.eu
> )
> > > but felt turned down and are now persuading me to trade the algorithms
> > > against SSL compression, than just say so please. I'll see what I can
> > > do.
> >
> > The whole world is trying to move away from TLS compression (which has
> > been removed from TLS 1.3). It has nothing to do with you.
>
> As I understand it, TLS is a predecessor of SSL. People are trying to move
> away from TLS, not from compression.
>

Then you don't understand it.

SSL is the predecessor to TLS. TLS has more or less entirely replaced SSL
-- only extremely outdated systems use SSL. TLSv1 followed after SSLv3.

People are moving *to* TLS. And in particular, TLS v1.3 made significant
and important changes. Compression was dropped from TLS v1.3 because it's
considered obsolete.

Again, compression is a perfectly valid usecase. But it shouldn't be, and
is no longer, a part of the encryption layer. Unfortunately, PostgreSQL
used to rely on it being that, so once it was removed from there, there is
no built-in support for compression.

One way to handle it, which is a bit ugly, is to tunnel the data through a
VPN or something like that which can enable compression.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>