Recent vendor SSL renegotiation patches break PostgreSQL
in [PgSql]
|
Prev: [HACKERS] Partial Page Writes documentaiton mention
Next: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
From: Robert Haas on 3 Feb 2010 10:03 On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell <chris_campbell(a)mac.com> wrote: > The flurry of patches that vendors have recently been making to OpenSSL to address > the potential man-in-the-middle attack during SSL renegotiation have disabled SSL > renegotiation altogether in the OpenSSL libraries. Applications that make use of SSL > renegotiation, such as PostgreSQL, start failing. Should we think about adding a GUC to disable renegotiation until this blows over? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 3 Feb 2010 10:21 Robert Haas <robertmhaas(a)gmail.com> writes: > Should we think about adding a GUC to disable renegotiation until this > blows over? Bad idea: once set, it'll never get unset, thus leaving installations with a weakened security posture even after they've installed fixed versions of openssl. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 3 Feb 2010 10:28 On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> Should we think about adding a GUC to disable renegotiation until this >> blows over? > > Bad idea: once set, it'll never get unset, thus leaving installations > with a weakened security posture even after they've installed fixed > versions of openssl. That's a problem, but our current posture of holding our breath doesn't seem to be working either. If we insist on shipping code that doesn't work with currently-distributed versions of OpenSSL, people will do things like, say, shut SSL off. Or packagers of PostgreSQL will apply patches that disable it unconditionally, leaving us with no control. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 3 Feb 2010 13:44 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > FWIW I think there's another problem with streaming replication here, > which is that most data flows from client to server, so it would take > quite some time for the threshold to be reached. Note that there's no > size check in the libpq frontend code. Normally this is not an issue > because the bulk of data is expected to flow in the other direction. Huh? I thought the slaves connect to the master, rather than the other way round? It's true that libpq doesn't contain any such code, but that seems like a fortunate thing right at the moment, as it limits the number of places we might have to hack something. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Michael Ledford on 3 Feb 2010 10:55
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > Bad idea: once set, it'll never get unset, thus leaving installations > with a weakened security posture even after they've installed fixed > versions of openssl. > > regards, tom lane One might argue that the current method is already weakened as it is measured by the amount of data sent instead of of a length of time. A session could live a long time under the 512MB threshold depending on the queries that are being performed. Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |