Re: SSL compression

On Mon, 2021-11-08 at 10:20 +0100, Magnus Hagander wrote:
> 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.

Yes, I am aware of the fact that it is pretty much useless to compress an already encrypted data source, the other way around indeed makes more sense.
After reading the link, it looks to me that this attacker has for some reason, knowledge of the original unencrypted and uncompressed data or even uses its own
data (The attacker then observes the change in size of the compressed request payload, which contains both the secret cookie that is sent by the browser only
to the target site, and variable content created by the attacker, as the variable content is altered), which is certainly never the case in a PostgreSQL data
transmission. Actually, I don't really see this happening. I've checked all the references, and in my opinion they're all pretty much non-believers. I have more
faith in huffman encoding and encryption than I have in these guys, that's for sure.
> 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.

That's too bad! Perhaps an idea for future development?
> > > > 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.
>