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 20 Feb 2010 12:55 Bruce Momjian <bruce(a)momjian.us> writes: > Tom Lane wrote: >> 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. > Is there anything remaining to do on this issue? I'm not sure. My impression is that by the time we had anything in the field, there will be real fixes for the SSL renegotiation problem. So all we'd be accomplishing is to weaken security for people who have those fixes, to cater to people who are using copies of openssl they'd obtained in the past couple of months and then not updated to latest. However, if anyone thinks that the SSL problem isn't going to get fixed promptly, maybe it needs more consideration. 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: Magnus Hagander on 22 Feb 2010 11:42 2010/2/20 Tom Lane <tgl(a)sss.pgh.pa.us>: > Bruce Momjian <bruce(a)momjian.us> writes: >> Tom Lane wrote: >>> 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. > >> Is there anything remaining to do on this issue? > > I'm not sure. My impression is that by the time we had anything in the > field, there will be real fixes for the SSL renegotiation problem. > So all we'd be accomplishing is to weaken security for people who have > those fixes, to cater to people who are using copies of openssl they'd > obtained in the past couple of months and then not updated to latest. > However, if anyone thinks that the SSL problem isn't going to get fixed > promptly, maybe it needs more consideration. The problem with this is, I think, that there are "semi-patched" versions of OpenSSL out there, that simply *break*. Instead of not doing renegotiation when we ask for it, they break it and return an error, thus canceling the connection. Correct? If so, shouldn't we try to disable renegotiation for all versions *before* it was properly fixed? Which today means all versions released. The proper fix is in 0.9.8m, which is currently in beta. At least that's my understanding. The way I read it, the code now does: * If the user has an old version of openssl, exposes the user to the security issue and makes the connection insecure * OpenSSL 0.9.8l, breaks the connection whenever renegotiation happens, but doesn't compromise security * OpenSSL 0.9.8m-beta, does the right thing. Do we have any idea of what people like RHEL are doing wrt backpatching these things? -- 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 11:54 Magnus Hagander <magnus(a)hagander.net> writes: > If so, shouldn't we try to disable renegotiation for all versions > *before* it was properly fixed? If we could tell that, sure. But I don't believe there is any way to identify whether a given installation of openssl has this patched. Please don't suggest looking at the version number --- Red Hat and other vendors are in the habit of back-patching security fixes without changing the version number. > Which today means all versions released. The proper fix is in 0.9.8m, > which is currently in beta. At least that's my understanding. Red Hat's already shipping the patch. Dunno about other vendors. The real bottom line here is that this isn't our bug. It's unfortunate that we're affected by it, but that doesn't mean that we should be installing kluges to work around 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: Magnus Hagander on 22 Feb 2010 12:00 2010/2/22 Tom Lane <tgl(a)sss.pgh.pa.us>: > Magnus Hagander <magnus(a)hagander.net> writes: >> If so, shouldn't we try to disable renegotiation for all versions >> *before* it was properly fixed? > > If we could tell that, sure. But I don't believe there is any way to > identify whether a given installation of openssl has this patched. > Please don't suggest looking at the version number --- Red Hat and > other vendors are in the habit of back-patching security fixes without > changing the version number. That, if anything, is a bug :( But yes, it's a bug lots of linux distros seem to consider a feature :( >> Which today means all versions released. The proper fix is in 0.9.8m, >> which is currently in beta. At least that's my understanding. > > 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 real bottom line here is that this isn't our bug. It's unfortunate > that we're affected by it, but that doesn't mean that we should be > installing kluges to work around it. True. But people will call it our problem. 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. There are probably people who would like to change it, but there certainly haven't been enough of them so we've heard lots of complains. And it's definitely not back-patchable. 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. -- 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 12:25
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. 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. > 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. > 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. 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 |