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 nice to 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 compression is being considered unsafe / insecure?
Transmissions to areas outside of Europe cost €5/mb at the moment and that makes SSL compression, or compression in general a vital component of d
ata transmissions.
Might the underlying reason be, that certain people have shown interest in my libpq/PQblockwrite algorithms (
/messages/by-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel@cyberfiber.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.
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 (
/messages/by-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel@cyberfiber.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?
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.
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 (
/messages/by-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel@cyberfiber.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.
Show quoted text
-- 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?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 (
/messages/by-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel@cyberfiber.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/>
At 2021-11-08 10:10:55 +0100, mjbaars1977.pgsql.hackers@gmail.com wrote:
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?
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
SSLENCRYPTED 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?
Show quoted text
Might the underlying reason be, that certain people have shown
interest in my libpq/PQblockwrite algorithms (
/messages/by-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel@cyberfiber.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.