Re: disable SSL compression?

On 9 March 2018 at 03:23, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:

> On Thu, Mar 8, 2018 at 3:40 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> > It appears that SSL compression is nowadays deprecated as insecure.
> > Yet, it is still enabled by libpq by default, and there is no way to
> > disable it in the server. Should we make some changes here? Does
> > anyone know more about this?
>
> Even if libpq enables it, it has to be enabled both in the client and
> the server for it to work.
>
> OpenSSL disables the whole feature by default, and enabling it is
> rather cumbersome. The result is that, at least with OpenSSL, the
> server and client won't accept compression without extensive fiddling
> by the user.
>
> So I don't think libpq has to change anything here.
>
>

So SSL compression is unsafe, deprecated and unavailable. Maybe it's time
to look at native protocol compression[1] again?

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.

However, I already proposed [2] way to handle such protocol extensions in a
way that will address this concern anyway, and more importantly will
present a more informative error to the user if the client doesn't support
the requested protocol option. We send what's effectively an ERROR with a
special SQLSTATE that clients that understand compression may ignore.
Anything that doesn't understand it will see it as a connection error.

I think that strategy would actually work well for a number of possible
protocol extensions that can be client-requested.

That doesn't automagically give us protocol compression. We'd still need a
way to indicate the start/end of a range of compressed payloads; we don't
want to compress each individual message payload independently, but also
need to be able to recover from errors. Presumably after a Sync the
receiver would be expected to treat subsequent message payloads as
uncompressed, or we'd extend Sync with a flag for whether compression in
subsequent messages is on or not. By never compressing the message type and
length we'd make sure we could always read the protocol stream, at the cost
of some waste. But we could still use the same deflate state across
successive message bodies for efficient compression of big CopyData
streams, result sets, etc.

Any thoughts on this model for client-requested protocol extensions? I've
been stymied a number of times by being unable to have the client ask the
server to send things that require a protocol change, and I think this is
possibly a solidly backward compatible way to handle it.

[1] https://www.postgresql.org/message-id/CADT4RqCKfawgwa735s_
brELaJ8ySutCC-u3iyLL_EEsJQDYFrg%40mail.gmail.com

[2] https://www.postgresql.org/message-id/CAMsr%2BYH0N7TaAtvS2hu-
y8LBkA25fJs0oungGe-tNhwr7scLSQ%40mail.gmail.com

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