From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Andreas Karlsson <andreas@proxel.se>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
Date: Mon, 11 Feb 2019 17:56:24 +0300
Message-ID: <c04c778a-dafb-d206-9db8-2001e670b8b7@postgrespro.ru> (raw)
In-Reply-To: <8d210267-a2fa-662f-b167-0e5991d45dd7@proxel.se>
References: <aad16e41-b3f9-e89d-fa57-fb4c694bec25@postgrespro.ru>
<20190208071431.skfmpbeclrkpzuac@alap3.anarazel.de>
<8d210267-a2fa-662f-b167-0e5991d45dd7@proxel.se>
On 11.02.2019 2:36, Andreas Karlsson wrote:
> I will preface this with that I am not a security guy and that also do
> not know how the Zstd vompression works, so take any of what I say
> with a grain of salt.
>
> On 2/8/19 8:14 AM, Andres Freund wrote:> I think compression is pretty
> useful, and I'm not convinced that the
>> threat model underlying the attacks on SSL really apply to postgres.
> I think only because it is usually harder to intercept traffic between
> the application server and the database than between the we bbrowser
> and the web server.
>
> Imagine the following query which uses the session ID from the cookie
> to check if the logged in user has access to a file.
>
> SELECT may_download_file(session_id => $1, path => $2);
>
> When the query with its parameters is compressed the compressed size
> will depend on the similarity between the session ID and the requested
> path (assuming Zstd works similar to DEFLATE), so by tricking the web
> browser into making requests with specifically crafted paths while
> monitoring the traffic between the web server and the database the
> compressed request size can be use to hone in the session ID and steal
> people's login sessions, just like the CRIME attack[1].
>
> So while compression is a very useful feature I am worried that it
> also opens application developers to a new set of security
> vulnerabilities which they previously were protected from when
> compression was removed from SSL.
>
> 1. https://en.wikipedia.org/wiki/CRIME
>
> Andreas
Andreas? thank you for clarification. Such kind of attack is really
possible.
But as far as I understand such attack requires injection between
server and database (to be able to analyze traffic between them).
Also such attack is possible only if session_id can be somehow
"guessed". If it is just big random number, then it is very unlikely
that it can be hacked in in this way.
But once again - I am not expert in cryptography.
And this patch is not addressing SSL vulnerabilities when using
compression - I agree, that compression at libpq level is not safer than
SSL level compression.
The goal was to support compression without using SSL. It seems to me
that there are many cases when security is not requires, but reducing
network traffic is desired.
The best example is replication between node in local network.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: k.knizhnik@postgrespro.ru, andreas@proxel.se, andres@anarazel.de
Subject: Re: libpq compression
In-Reply-To: <c04c778a-dafb-d206-9db8-2001e670b8b7@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox