On Wed, Feb 24, 2010 at 17:47, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
2010/2/24 Tom Lane t...@sss.pgh.pa.us:
Also, the coding seems a bit confused about whether the
ssl_renegotiation_limit GUC exists when USE_SSL isn't set. I think we
have a project
On Thu, Feb 25, 2010 at 10:42, Magnus Hagander mag...@hagander.net wrote:
On Wed, Feb 24, 2010 at 17:47, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Fair enough, USERSET it is then.
Done. Will run some tests and then apply.
And applied.
I backpatched it to
Magnus Hagander mag...@hagander.net writes:
On Wed, Feb 24, 2010 at 17:47, Tom Lane t...@sss.pgh.pa.us wrote:
I see that ssl_ciphers is made to go away when USE_SSL isn't set,
so the most consistent thing in the near term would be to do the same.
The difference is that ssl_ciphers is only set
On Thu, Feb 25, 2010 at 15:27, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Feb 24, 2010 at 17:47, Tom Lane t...@sss.pgh.pa.us wrote:
I see that ssl_ciphers is made to go away when USE_SSL isn't set,
so the most consistent thing in the near term would
Magnus Hagander mag...@hagander.net writes:
I backpatched it to 8.2, which is as far as it applied fairly cleanly.
Before that, we don't have GUC_UNIT_KB for example, so it'll be a
different format of the patch as well. I'm not sure it's important
enough to go back beyond that...
Hm, I'd
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
If you want to do it, I'd be fine with it.
Seems easy enough, see attached. Comments?
Looks mostly okay to me, a few notes:
+ if (ssl_renegotiation_limit port-count
ssl_renegotiation_limit *
2010/2/24 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
If you want to do it, I'd be fine with it.
Seems easy enough, see attached. Comments?
Looks mostly okay to me, a few notes:
+ if (ssl_renegotiation_limit
Magnus Hagander mag...@hagander.net writes:
2010/2/24 Tom Lane t...@sss.pgh.pa.us:
Also, the coding seems a bit confused about whether the
ssl_renegotiation_limit GUC exists when USE_SSL isn't set. I think we
have a project policy about whether GUCs should still exist when the
underlying
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
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
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
2010/2/23 Albe Laurenz laurenz.a...@wien.gv.at:
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
2010/2/20 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Chris Campbell chris_campb...@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
Magnus Hagander mag...@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
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@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
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@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
On Mon, 22 Feb 2010 12:25:08 -0500, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@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
On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander mag...@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
2010/2/22 Joshua D. Drake j...@commandprompt.com:
On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander mag...@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
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
On Mon, 2010-02-22 at 18:45 +0100, Magnus Hagander wrote:
2010/2/22 Joshua D. Drake j...@commandprompt.com:
On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander mag...@hagander.net
wrote:
We also have to consider our Windows users, where *we* ship the
OpenSSL library. Where there is no
On 2/22/10, Joshua D. Drake j...@commandprompt.com wrote:
On Mon, 2010-02-22 at 18:45 +0100, Magnus Hagander wrote:
2010/2/22 Joshua D. Drake j...@commandprompt.com:
On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander
mag...@hagander.net
wrote:
We also have to consider our Windows
2010/2/22 Chris Campbell chris_campb...@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
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@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
Magnus Hagander mag...@hagander.net writes:
2010/2/22 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@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
Tom Lane wrote:
Chris Campbell chris_campb...@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
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Chris Campbell chris_campb...@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
On Feb 3, 2010, at 10:16 AM, Stefan Kaltenbrunner wrote:
Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell chris_campb...@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
Greetings, hackers!
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
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell chris_campb...@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
Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell chris_campb...@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
Robert Haas robertmh...@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.
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@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
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane t...@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
Michael Ledford mledf...@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.
Is there a way to detect when the SSL library has renegotiation disabled?
(Either at compile-time or runtime, although runtime would definitely be better
because we’ll change our behavior if/when the user updates their SSL library.)
If so, we could skip renegotiation when it’s disabled in the
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane t...@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?
Chris Campbell chris_campb...@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
On Wed, Feb 3, 2010 at 11:52 AM, Michael Ledford mledf...@gmail.com wrote:
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane t...@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
Tom Lane wrote:
Chris Campbell chris_campb...@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
Tom Lane escribió:
Michael Ledford mledf...@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
Alvaro Herrera alvhe...@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
Tom Lane wrote:
Alvaro Herrera alvhe...@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
42 matches
Mail list logo
