Re: Wire protocol compression

On 21 April 2016 at 22:21, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:

> Wouldn't such a solution be just as vulnerable to CRIME as TLS is? I
> thought the reason for removing compression from TLS is to discourage
> people from writing applications which are vulnerable to compression based
> attacks by not proving an easy for people to just compress everything.
> <http://www.postgresql.org/mailpref/pgsql-hackers>
>

Probably... but you could then use compression without encryption without
hacks like forcing a noop cipher. If you're running traffic over a VPN WAN
link or something that could be a pretty sensible option. OTOH, such a VPN
may have its own compression, rendering compression by Pg unnecessary. The
downside is that the VPN overheads can be considerable as can the general
performance impact.

Personally I admit I just don't care that much about the CRIME attack for
most of the deployments I'm interested in. It requires the attacker be able
to make alterations on the server.

"The attacker then observes the change in size of the compressed request
payload, which contains both the secret cookie that is sent by the browser
only to the target site, and variable content created by the attacker, as
the variable content is altered."

https://en.wikipedia.org/wiki/CRIME

I'm not especially concerned that authorized user 'unpriv-1' can hijack
user 'super' 's connections if unpriv-1 can somehow modify tables super is
reading *and* snoop super's traffic, doing it all on a tight schedule.
We've probably got bigger security issues than that.

Our auth salting helps a lot anyway, and while there are situations where a
privileged user could be fetching some slow-changing short and
security-critical content repeatedly from a table as part of a join the
unprivileged user can modify data in, I'm again just not that concerned.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services