On 21 April 2016 at 22:21, Andreas Karlsson <andreas@proxel.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.
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."
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.
