Re: [BUGS] BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL'ssslcompression assumption, defaults to SSL_OP_NO_COMPRESSION
| От | Laurence Parry |
|---|---|
| Тема | Re: [BUGS] BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL'ssslcompression assumption, defaults to SSL_OP_NO_COMPRESSION |
| Дата | |
| Msg-id | HE1PR08MB28920BC501DE272A685E6796A5F40@HE1PR08MB2892.eurprd08.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: [BUGS] BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompression assumption, defaults to SSL_OP_NO_COMPRESSION (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-bugs |
> So the actual issue here, which you've not addressed in
> this otherwise extensive screed, is whether it's a wise
> thing for us to override that decision.
>
> Is there some reason why PG data is immune to the CRIME attack?
I didn't address the security implications because I am not a security expert.
It would be a good idea for a security professional to evaluate the protocol.
If you want, I can make a few guesses, to be taken with a large pinch of salt:1) Many PostgreSQL connections operate over networks which are believed to be secure. This came up last year in postgres-hackers, and there were others who felt that CRIME was not a significant concern in most of their deployments:
In this case, administrators may be using SSL *only* for the compression benefits, because there is no separate compression feature. There is still an argument for defence-in-depth, but it is not as compelling in such situations.
[Bear in mind that unexpected loss of compression - say, after upgrading a standby - can impact the stability of a replication setup with specified bandwidth limits. Suddenly, the load triples - perhaps 5Mbps -> 15Mbps, on a 10Mbps leased line. Replication lags, WAL backs up - and before you know it, you're out of disk space on the *primary*, without even touching it. This may only be noticed once the server gets busy - say, after the maintenance window in which you upgraded the standby - and is compounded by the fact that the only way you know what's happened is by capturing the SSL handshakes, or deduce it from the change in bandwidth usage.]
2) HTTPS is particularly vulnerable to CRIME because unrelated information (much of which the attacker knows and/or controls) is regularly compressed and transferred with a static authentication cookie which they want to discover.
PostgreSQL does not handle authentication in quite the same way. It is done only at connection startup; credentials are transferred separately from other data, and the authentication persists for the connection lifetime, which is often extensive:
Now, ZLIB-based SSL compression is stateful, so if an attacker can get a client to open many connections, they might be vulnerable if they can also get information into the first 32KB transmitted and draw an inference from there. But it's likely to be harder to determine a match, especially if they don't know the queries being made.
3) Applications which are separated from the database over a network are also likely to be using a connection pooler, which holds open a set of of active connections and does not consistently repeat authentication when new requests are made.
4) In my own use-case, network connections are only used for replication, which doesn't have the multiple-connections issue - if a slot is in use, the master will refuse additional connections (I know this well from using a somewhat unreliable WAN). Maybe there is some MITM attack which could be used to repeatedly drop and re-establish the connection, but this is likely to be noticeable in the logs/performance. If using certificates for identification, that kind of attack should be infeasible.
5) A WAL stream or other connection might contain other data which they could try to match. But even if specific plaintext can be inserted, *and* they can get a secret included too, an active connection is likely transferring other content as well. It lacks the same consistency as as a stream of POSTs which the attacker controls, containing a constant secret at a constant location. (synchronous_commit='off' may make this harder, though I don't know how immediate streaming replication is.)
> Should we not just change sslcompression into a no-op?
Well, it effectively *is* a no-op on OpenSSL 1.1.0+. That's what I want to fix! Losing the ability to compress the transport should, in itself, be considered a regression. I don't think every PostgreSQL user on a modern OS should have to patch their copy of OpenSSL because PostgreSQL isn't doing what it claims to. :-)
Making sslcompression a no-op would also stop administrators from disabling SSL compression just for PostgreSQL on platforms where it *is* on by default - i.e. OpenSSL 0.9.8x/1.0.x where the distro hasn't patched-out ZLIB - which is currently the point of the parameter.
I guess maybe you meant it should always set no-compression? There's an argument that PostgreSQL's defaults should be the safest possible. From that perspective, it may be reasonable to change the default to not be compressed, at least for 10. But even if this is done, PostgresSQL should clear the no-compression flag if sslcompression=1, as that is a clear expression of intent by the administrator.
PostgreSQL is used in a variety of situations. In some of those, SSL compression may be seen as inadvisable. In others, it is beneficial. This is about making sure administrators can continue to choose it as an option based on their situation.
PostgreSQL already trusts administrators to make decisions about security trade-offs, otherwise it might forbid connections without SSL entirely - or at least have 'require' rather than 'prefer' as a default. It _would_ be a good idea to communicate concerns in the documentation, so administrators can make more-educated decisions.
> In short I'm wondering whether app-driven transport data
> compression is an idea whose time has passed.
If anything it seems far *more* suitable for the app to do it vs. delegating to the transport, because it has knowledge of the sensitivity of the data.
For example, it might use a stateless ZLIB replacement ( http://www.libslz.org/ ) during the authentication phase, and revert to regular ZLIB operation during WAL streaming. Or just use SLZ all the time, accepting that compression will be worse (but still with a ~55% saving), and faster to boot.
But that would be a separate feature. This bug is about preserving an existing documented feature, which is seen as useful in many use-cases:
...at least until there is a good replacement for it.--
Laurence "GreenReaper" Parry
В списке pgsql-bugs по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: [BUGS] BUG #14664: Nonsensical join selectivity estimation despite n_distinct
Следующее
От: Noah MischДата:
Сообщение: [BUGS] Re: BUG #14680: startup process on standby encounter a deadlock ofTwoPhaseStateLock when redo 2PC xlog