Re: disable SSL compression?

On 09. 03. 2018 06:24, Craig Ringer wrote:
> 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