Re: libpq compression - Mailing list pgsql-hackers

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