Re: disable SSL compression?

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