On Tue, Jan 15, 2013 at 01:35:57PM +0000, Greg Stark wrote:
> On Tue, Jan 15, 2013 at 2:33 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Peter Eisentraut (peter_e@gmx.net) wrote:
> >> On 1/14/13 11:28 AM, Stephen Frost wrote:
> >> > While there is no option currently for having the server do the
> >> > compression before sending the data over the wire.
> >>
> >> OpenSSL?
> >
> > To be honest, I expected that to come up earlier in this discussion.
> > It'd be redundant to use OpenSSL for compression and then ALSO do
> > compression on the client side to save into a custom format dump.
>
> For what it's worth there was a security announcement not long ago
> that made OpenSSL disable compression in streams by default. I'm not
> sure if it's relevant to Postgres or not.
It's an interesting question. It might be. I thought at first it
wouldn't be relevant, but on reflection it is.
This attack is called the CRIME attack. This class of attacks stem from reuse
of a dictionary across some sort of confidentiality boundary. The attacker
looks at the traffic and notices 'how big' the network response is. This
tells the attacker the compressor has seen already seem the text.
So imagine, I have a website and I keep session cookies, user names, and
password crypts in a database. Imagine the session key is a long
hexidecimal number. As an attacker, I could send in the username field
of the login form guesses of the prefix of somebody else's session key
I peek at the encrypted traffic from script to the database. As the
prefix match length increases the database reply gets shorter.
Essentially, its a side channel attack that ends up reducing guessing to
a radix search by prefix of all valid session keys. In this attack, I
don't have access to the database except through the web form, but I
can see the encrypted database traffic.
It is not a huge vulnerability, but yeah in some use cases if postgresql
used compression it might provide a difficult, but possible route.
Garick