Re: disable SSL compression?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Subject: Re: disable SSL compression?
Date: 2018-04-02 15:05:25
Message-ID: CA+Tgmoa_AkOYHV83F4ZjbnPMGcZ4oDLb28gLtdEBOwYqC8MOmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 2, 2018 at 10:52 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 4/2/18 10:25, Robert Haas wrote:
>> As I understand it on a brief review of the Google search
>> results^W^W^Wliterature, the reason that was done was to prevent
>> things like the CRIME attack, which apparently involves Javascript
>> running in your browser from deducing information that it shouldn't be
>> able to get, like the Cookies that are sent along with the requests it
>> initiates. No similar attack should be possible against PostgreSQL
>> because there's no similar kind of privilege separation. Your PG
>> driver doesn't have untrusted Javascript running inside of it, we
>> hope.
>
> I think the attack is much more general involving two server end points,
> one of which is under the control of the attacker and provides
> information that the client is using to query the second server,
> independent of the protocols.
>
> For example, if your application code does maybe a geoip lookup and then
> does
>
> select * from sometable
> where a = $geo_data and b = 'secret bank account number';
>
> then the operator of the geoip service (or someone impersonating it, of
> course) can just rotate the lookup results through the bank account
> number space until they notice that the compression result changes, in
> which case they have matched the bank account number.
>
> In the web space, that is easier because the client code is typically
> viewable by the attacker, and this kind of query is more common (the
> "bank account number" is typically a session key), but the principle is
> the same.

Ah. Yeah, that makes sense. Although to use PG as a vector, it seems
like the attacker would need to the ability to snoop network traffic
between the application server and PG. If both of those are
presumably inside the bank's network and yet an attacker can sniff
them, to some degree you've already lost. Now it could be that a
rogue bank employee is trying to gain access from within the bank, or
maybe your bank exposes application-to-database traffic on the public
Internet. But in general that seems like traffic that should be
well-secured anyway for lots of reasons, as opposed to the case where
one part of your browser is trying to hide information from another
part of your browser, which is a lot harder to isolate thoroughly.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2018-04-02 15:07:17 Re: Feature Request - DDL deployment with logical replication
Previous Message Bossart, Nathan 2018-04-02 15:04:16 Re: Change RangeVarGetRelidExtended() to take flags argument?