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: Tom Lane on 3 Feb 2010 11:09 Michael Ledford <mledford(a)gmail.com> writes: > 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. Renegotiation after X amount of data is the recommended method AFAIK, because it limits the volume of data available to cryptanalysis. What makes you think that elapsed time is relevant at all? 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: Tom Lane on 3 Feb 2010 11:58 Chris Campbell <chris_campbell(a)mac.com> writes: > Is there a way to detect when the SSL library has renegotiation disabled? Probably not. The current set of emergency security patches would certainly not have exposed any new API that would help us tell this :-( If said patches were done properly they'd have also turned an application-level renegotiation request into a no-op, instead of breaking apps by making it fail --- but apparently they were not done properly. 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 12:04 On Wed, Feb 3, 2010 at 11:52 AM, Michael Ledford <mledford(a)gmail.com> wrote: > On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Renegotiation after X amount of data is the recommended method AFAIK, >> because it limits the volume of data available to cryptanalysis. >> What makes you think that elapsed time is relevant at all? > > You are correct. In that volume of data also matters. It depends on > what kind of attack you are trying to minimize here. In my particular > use case I fluctuate between idle and busy but mostly low bandwidth. > > You have four different primary cases that you are possible: This may all be true, but I think we're getting off track. If we force ANY negotiation (whether based on time or bytes transferred), we will, apparently, break things. So I think that means we should have a way to disable that behavior, for fear of dissuading people from using SSL (or PostgreSQL) altogether, or hacking their own copies of the source in ways that may be even uglier. ....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: Michael Ledford on 3 Feb 2010 11:52 On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > Renegotiation after X amount of data is the recommended method AFAIK, > because it limits the volume of data available to cryptanalysis. > What makes you think that elapsed time is relevant at all? > > regards, tom lane You are correct. In that volume of data also matters. It depends on what kind of attack you are trying to minimize here. In my particular use case I fluctuate between idle and busy but mostly low bandwidth. You have four different primary cases that you are possible: 1) timed method on an idle link (or low usage) 2) timed method on a busy link (or high usage) 3) data limit on an idle link (or low usage) 4) data limit on a busy link (or high usage) The timed method is more optimal for case 1. The data limit is more optimal for case 4. Case 2 gives an attacker more data to do crypto-analysis. Case 3 gives an attacker more time to work with the current secret key on a live link. Depending on your use case, being able to work with a live link is worse than working with the data postmortem. There is I'm sure some hybrid in the middle between these where optimal lives. 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
From: Heikki Linnakangas on 4 Feb 2010 01:42
Tom Lane wrote: > 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? Correct, slave connects to the master. Alvaro is pointing out that most data flows from client to server, like in COPY FROM. But the server counts both in- and out-going data against the renegotiation limit, so the server will initiate renegotiation just fine in that case too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |