Magnus Hagander 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 kinda like to have i
On Thu, Feb 25, 2010 at 15:27, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Feb 24, 2010 at 17:47, Tom Lane 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
Magnus Hagander writes:
> On Wed, Feb 24, 2010 at 17:47, Tom Lane 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 in postgresql.conf, so
> it doe
On Thu, Feb 25, 2010 at 10:42, Magnus Hagander wrote:
> On Wed, Feb 24, 2010 at 17:47, Tom Lane wrote:
>> Magnus Hagander writes:
>> Fair enough, USERSET it is then.
>
> Done. Will run some tests and then apply.
And applied.
I backpatched it to 8.2, which is as far as it applied fairly cleanly
On Wed, Feb 24, 2010 at 17:47, Tom Lane wrote:
> Magnus Hagander writes:
>> 2010/2/24 Tom Lane :
>>> 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 w
Magnus Hagander writes:
> 2010/2/24 Tom Lane :
>> 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 support isn't compiled, but I fo
2010/2/24 Tom Lane :
> Magnus Hagander writes:
>> 2010/2/22 Tom Lane :
>>> 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_limi
Magnus Hagander writes:
> 2010/2/22 Tom Lane :
>> 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 * 1024)
You need "1024L" there t
2010/2/23 Albe Laurenz :
> 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/22 Tom Lane :
> Magnus Hagander writes:
>> 2010/2/22 Tom Lane :
>> 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
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
Magnus Hagander writes:
> 2010/2/22 Tom Lane :
>> Magnus Hagander 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, th
2010/2/22 Tom Lane :
> Magnus Hagander writes:
>> 2010/2/22 Tom Lane :
>>> 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'
2010/2/22 Chris Campbell :
> 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
>>
On 2/22/10, Joshua D. Drake wrote:
> On Mon, 2010-02-22 at 18:45 +0100, Magnus Hagander wrote:
>> 2010/2/22 Joshua D. Drake :
>> > On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander
>> >
>> > wrote:
>> >
>> >> We also have to consider our Windows users, where *we* ship the
>> >> OpenSSL library.
On Mon, 2010-02-22 at 18:45 +0100, Magnus Hagander wrote:
> 2010/2/22 Joshua D. Drake :
> > On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander
> > 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
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 t
2010/2/22 Joshua D. Drake :
> On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander
> 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
On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander
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 provi
On Mon, 22 Feb 2010 12:25:08 -0500, Tom Lane wrote:
> Magnus Hagander writes:
>> 2010/2/22 Tom Lane :
>>> 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.
>
Magnus Hagander writes:
> 2010/2/22 Tom Lane :
>> 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 sensib
2010/2/22 Tom Lane :
> Magnus Hagander 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.
> Pl
Magnus Hagander 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 th
2010/2/20 Tom Lane :
> Bruce Momjian writes:
>> Tom Lane wrote:
>>> Chris Campbell 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 woul
Bruce Momjian writes:
> Tom Lane wrote:
>> Chris Campbell 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 :-(
>>
Tom Lane wrote:
> Chris Campbell 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 pr
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
>> wrote:
>>> The flurry of patches that vendors have recently been making to OpenSSL to
>>> address
>>> the potential man-in-the-middle attack during SSL renegotiatio
Tom Lane wrote:
> Alvaro Herrera 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 c
Alvaro Herrera 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
Tom Lane escribió:
> Michael Ledford 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 p
Tom Lane wrote:
> Chris Campbell 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 pr
On Wed, Feb 3, 2010 at 11:52 AM, Michael Ledford wrote:
> On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane 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 rele
Chris Campbell 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
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane 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
Y
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 li
Michael Ledford 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 afte
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane 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 met
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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.
regard
Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell 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. Appl
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell 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 tha
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 Po
42 matches
Mail list logo
