Re: SSL compression
| От | Magnus Hagander |
|---|---|
| Тема | Re: SSL compression |
| Дата | |
| Msg-id | CABUevEyoMxzXxKdRyv+B39bw3ynBX2Uamfrvm1q7NQaB0tYH9Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SSL compression ("Michael J. Baars" <mjbaars1977.pgsql.hackers@gmail.com>) |
| Ответы |
Re: SSL compression
("Michael J. Baars" <mjbaars1977.pgsql.hackers@gmail.com>)
|
| Список | pgsql-hackers |
On Mon, Nov 8, 2021 at 10:11 AM Michael J. Baars <mjbaars1977.pgsql.hackers@gmail.com> wrote:
On Mon, 2021-11-08 at 13:30 +0530, Abhijit Menon-Sen wrote:
> At 2021-11-08 08:41:42 +0100, mjbaars1977.pgsql.hackers@gmail.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.
В списке pgsql-hackers по дате отправления: