Обсуждение: SSL compression
Hi All, While I was searching for methods to send the result of a query to the other side of the world, because it might be niceto go there once in a while, I noticed my best option, SSL compression, has been disabled as of version 14. Could someone please explain to me, why compressionis being considered unsafe / insecure? Transmissions to areas outside of Europe cost €5/mb at the moment and that makes SSL compression, or compression in generala vital component of d ata transmissions. 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 downand are now persuading me to trade the algorithms against SSL compression, than just say so please. I'll see what I can do. Best regards, Mischa Baars.
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 > 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. -- Abhijit
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 mightfeel safer communicating over an SSL ENCRYPTED line doing their daily business, unjustified as that is, but they shouldn't be feeling safer communicating overa compressed line, that would be utterly stupid. The sole purpose of compression is to reduce the size of a particular amount of data. > > 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. > > -- Abhijit
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.
At 2021-11-08 10:10:55 +0100, mjbaars1977.pgsql.hackers@gmail.com wrote: > > > https://en.wikipedia.org/wiki/CRIME > > Well Abhijit, personally I don't see any connection between crime and > compression. Reading the page I linked to may help you make the connection. If not, try any of the numerous other pages that talk about vulnerabilities in TLS related to compression. > As I understand it, TLS is a predecessor of SSL. No. SSL is the predecessor. > People are trying to move away from TLS, not from compression. No. -- ams
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.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.
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.