Re: libpq compression

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq compression
Date: 2019-02-11 15:51:40
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2019-02-11 12:46:07 -0300, Alvaro Herrera wrote:
> On 2019-Feb-11, Andreas Karlsson wrote:
> > 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].
> I would have said that you'd never let the attacker eavesdrop into the
> traffic between webserver and DB, but then that's precisely the scenario
> you'd use SSL for, so I suppose that even though this attack is probably
> just a theoretical risk at this point, it should definitely be
> considered.


> Now, does this mean that we should forbid libpq compression
> completely? I'm not sure -- maybe it's still usable if you encapsulate
> that traffic so that the attackers cannot get at it, and there's no
> reason to deprive those users of the usefulness of the feature. But
> then we need documentation warnings pointing out the risks.

I think it's an extremely useful feature, and can be used in situation
where this kind of attack doesn't pose a significant
danger. E.g. pg_dump, pg_basebackup seem candidates for that, and even
streaming replication seems much less endangered than sessions with lots
of very small queries. But I think that means it needs to be
controllable from both the server and client, and default to off
(although it doesn't seem crazy to allow it in the aforementioned
cases). I suspect we'd need a febe_compression = allow | off | on type
setting for both client and server, and it'd default to allow for both
sides (which means it'd not be used by default, but one side can opt


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Zakirov 2019-02-11 16:25:39 [PATCH] xlogreader: do not read a file block twice
Previous Message Chapman Flack 2019-02-11 15:51:25 Re: PostgreSQL vs SQL/XML Standards