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: Dave Page on 22 Feb 2010 14:00 On 2/22/10, Joshua D. Drake <jd(a)commandprompt.com> wrote: > On Mon, 2010-02-22 at 18:45 +0100, Magnus Hagander wrote: >> 2010/2/22 Joshua D. Drake <jd(a)commandprompt.com>: >> > On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander >> > <magnus(a)hagander.net> >> > wrote: >> > >> >> We also have to consider our Windows users, where *we* ship the >> >> OpenSSL library. Where there is no library we can ship right now that >> >> fixes it. >> > >> > We do? I mean I know that we provide the old 8.2/8.3 pginstaller, but >> > EDB >> > is the provider of w32 binaries, not the community. >> >> How does that change the fact even a tiny bit for the end user? > > Only that EDB may chose to put in there own We're certainly not going to be shipping anything but standard PostgreSQL, and i don't have the cycles or energy to try building bespoke versions of openssl. -- 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: Magnus Hagander on 22 Feb 2010 14:34 2010/2/22 Chris Campbell <chris_campbell(a)mac.com>: > On Feb 22, 2010, at 12:25 PM, Tom Lane wrote: > >> I think we already missed the window where it would have been sensible >> to install a hack workaround for this. If we'd done that in November >> it might have been reasonable, but by now it's too late for any hack >> we install to spread much faster than fixed openssl libraries. > > Could we simply ignore renegotiation errors? Or change them to warnings? That may enable us to work with the semi-fixed OpenSSL libraries that are currently in the field, without disabling the functionality altogether. I guess we could, but if we do that then we've opened a window where someone can attack us if we *have* a properly working openssl, haven't we? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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
From: Magnus Hagander on 22 Feb 2010 14:39 2010/2/22 Tom Lane <tgl(a)sss.pgh.pa.us>: > Magnus Hagander <magnus(a)hagander.net> writes: >> 2010/2/22 Tom Lane <tgl(a)sss.pgh.pa.us>: >>> Red Hat's already shipping the patch. Dunno about other vendors. > >> Which patch? The one that breaks it, or the one that changes the protocol? > > The one with the protocol change. Ok. If RedHat has done it, I think we're in reasonably good shape. From what I can tell, Debian doesn't have the broken *or* non-broken patch in, but I'm not certain. > I think we already missed the window where it would have been sensible > to install a hack workaround for this. If we'd done that in November > it might have been reasonable, but by now it's too late for any hack > we install to spread much faster than fixed openssl libraries. Yeah, seems so. >> One way to deal with it would be to expose the whole renegotiation >> setting as a user configuratble option. So they can set *when* we >> renegotiate, which would also let them turn it off completely. > > Well, that might be a reasonable thing to do, because it's not just a > temporary kluge (that we won't know when to remove) but is adding an > arguably-useful-in-other-ways knob. Yeah, the question is, how useful is it? >> And it's definitely not back-patchable. > > Why not? We certainly wouldn't back-patch such a thing if we didn't > have a problem to deal with, but it's not like there's no precedent > for adding back-patched GUCs in response to security issues. We > did that with backslash_quote. Hmm, I guess. It's a new feature, but if it's necessary.. That would take care of things on Windows as well. We could then just disable renegotiation when we ship the known broken binaries. You'd still have to turn it off on the server side if you have a *single* client that has the broken patch, but that's still a lot better than nothing. Think it's worth taking a stab at? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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
From: Tom Lane on 22 Feb 2010 14:57 Magnus Hagander <magnus(a)hagander.net> writes: > 2010/2/22 Tom Lane <tgl(a)sss.pgh.pa.us>: >> Magnus Hagander <magnus(a)hagander.net> writes: >>> One way to deal with it would be to expose the whole renegotiation >>> setting as a user configuratble option. So they can set *when* we >>> renegotiate, which would also let them turn it off completely. >> >> Well, that might be a reasonable thing to do, because it's not just a >> temporary kluge (that we won't know when to remove) but is adding an >> arguably-useful-in-other-ways knob. > You'd still have to turn it off on the server side if you have a > *single* client that has the broken patch, but that's still a lot > better than nothing. Well, if it's a GUC it can be set per-user or per-database, so there's at least some hope of not having to turn it off for everyone. > Think it's worth taking a stab at? If you want to do it, I'd be fine with it. 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: "Albe Laurenz" on 23 Feb 2010 03:53
Tom Lane wrote: >>>> One way to deal with it would be to expose the whole renegotiation >>>> setting as a user configuratble option. So they can set *when* we >>>> renegotiate, which would also let them turn it off completely. >>> >>> Well, that might be a reasonable thing to do, because it's not just a >>> temporary kluge (that we won't know when to remove) but is adding an >>> arguably-useful-in-other-ways knob. > >> You'd still have to turn it off on the server side if you have a >> *single* client that has the broken patch, but that's still a lot >> better than nothing. > > Well, if it's a GUC it can be set per-user or per-database, so there's > at least some hope of not having to turn it off for everyone. > > > Think it's worth taking a stab at? > > If you want to do it, I'd be fine with it. +1 That would help me with a different problem: SSL renegotiation is broken with Npgsql, the cause is Bug 321325 in the Mono security library https://bugzilla.novell.com/show_bug.cgi?id=321325 which does not look like it is ever going to be fixed. Up to now I have crippled SSL renegotiation in our servers with a patch, because I figured that bad SSL is better than no SSL. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |