Re: disable SSL compression? - Mailing list pgsql-hackers

I'm totally unconvinced by the threat posed by exploiting a client by tricking it into requesting protocol compression - or any other protocol change the client lib doesn't understand - with a connection option in PGOPTIONS or the "options" connstring entry. The attacker must be able to specify either environment variables (in which case I present "LD_PRELOAD") or the connstr. If they can set a connstr they can direct the client to talk to a different host that tries to exploit the connecting client in whatever manner they wish by sending any custom crafted messages they like.

If the attacker has access to client process or environment, he's already won and this is not where the compression vulnerability lies.

CRIME and BREACH attacks with (SSL) compression are known plaintext attacks, which require the attacker 1) to have ability to observe encrypted data and 2) have a way to influence the plain text, in this case SQL query. In the case of CRIME HTTPS attack, compression state was shared between page content and request headers, thus by observing size of responses, which are in HTTP headers, one could guess cookie values and steal credentials even though the javascript making requests was running on different domain.

So the vulnerability would be in guessing some values in request or response, which the application or protocol might want to keep hidden, while somehow getting the size of request or response from database. Thus, sharing compression state too widely might not be wise.

Kind regards,
Gasper