s not a feature that PostgreSQL has,
> or ever
> had.
That's too bad! Perhaps an idea for future development?
> > > > Might the underlying reason be, that certain people have shown
> >
> > > > interest in my libpq/PQblockwrite algorithms (
> >
> > >
At 2021-11-08 10:10:55 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:
>
> > https://en.wikipedia.org/wiki/CRIME
>
> Well Abhijit, personally I don't see any connection between crime and
> compression.
Reading the page I linked to may help you make the connection. If not,
try any of the numerou
> > Might the underlying reason be, that certain people have shown
> > > interest in my libpq/PQblockwrite algorithms (
> > >
> https://www.postgresql.org/message-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel%40cyberfiber.eu
> )
> > > but felt turned down
ms (
> > https://www.postgresql.org/message-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel%40cyberfiber.eu)
> > but felt turned down and are now persuading me to trade the algorithms
> > against SSL compression, than just say so please. I'll see what I can
> > do.
>
> The whole world is trying
est in my libpq/PQblockwrite algorithms (
> https://www.postgresql.org/message-id/c7cccd0777f39c53b9514e3824badf276759fa87.camel%40cyberfiber.eu)
> but felt turned down and are now persuading me to trade the algorithms
> against SSL compression, than just say so please. I'll see what I
Hi All,
While I was searching for methods to send the result of a query to the other
side of the world, because it might be nice to go there once in a while, I
noticed
my best option, SSL compression, has been disabled as of version 14. Could
someone please explain to me, why compression is
On Sat, Mar 06, 2021 at 10:39:52AM +0900, Michael Paquier wrote:
> Okay, cool. I'd rather wait more for Peter before doing anything, so
> if there are no objections, I'll look at that stuff again at the
> beginning of next week and perhaps apply it. If you wish to take care
> of that yourself, pl
On Fri, Mar 05, 2021 at 05:44:20PM +0100, Magnus Hagander wrote:
> We've broken stats views before. While it'd be nice if we could group
> multiple breakages at the same time, I don't think it's that
> important. Better to get rid of it once and for all from as many
> places as possible.
Okay, coo
On Fri, Mar 5, 2021 at 1:37 PM Michael Paquier wrote:
>
> On Fri, Mar 05, 2021 at 01:21:01PM +0100, Daniel Gustafsson wrote:
> > On 5 Mar 2021, at 08:04, Michael Paquier wrote:
> >> FWIW, I would vote to nuke it from all those places, reducing a bit
> >> pg_stat_get_activity() while on it. Keepi
On Fri, Mar 05, 2021 at 01:21:01PM +0100, Daniel Gustafsson wrote:
> On 5 Mar 2021, at 08:04, Michael Paquier wrote:
>> FWIW, I would vote to nuke it from all those places, reducing a bit
>> pg_stat_get_activity() while on it. Keeping it around in the system
>> catalogs may cause confusion IMHO,
> On 5 Mar 2021, at 08:04, Michael Paquier wrote:
>
> On Thu, Mar 04, 2021 at 11:52:56PM +0100, Daniel Gustafsson wrote:
>> The attached version takes a step further and removes sslcompression from
>> pg_conn and just eats the value as there is no use in setting a dummy alue.
>> It
>> also remo
On Thu, Mar 04, 2021 at 11:52:56PM +0100, Daniel Gustafsson wrote:
> The attached version takes a step further and removes sslcompression from
> pg_conn and just eats the value as there is no use in setting a dummy alue.
> It
> also removes compression from PgBackendSSLStatus and be_tls_get_compr
> On 4 Mar 2021, at 11:59, Michael Paquier wrote:
>
> On Wed, Mar 03, 2021 at 03:14:01PM +0100, Peter Eisentraut wrote:
>> Per your other thread, you should also remove the environment variable.
>>
>> In postgres_fdw, I think commenting it out is not the right change. The
>> other commented out
> On 3 Mar 2021, at 15:14, Peter Eisentraut
> wrote:
>
> On 03.03.21 11:31, Daniel Gustafsson wrote:
>>> On 26 Feb 2021, at 20:34, Daniel Gustafsson wrote:
>>> Attached is a v2 which retains the sslcompression parameter for backwards
>>> compatibility.
>> And now a v3 which fixes an oversight i
On Wed, Mar 03, 2021 at 03:14:01PM +0100, Peter Eisentraut wrote:
> Per your other thread, you should also remove the environment variable.
>
> In postgres_fdw, I think commenting it out is not the right change. The
> other commented out values are still valid settings but are omitted from the
>
On 03.03.21 11:31, Daniel Gustafsson wrote:
On 26 Feb 2021, at 20:34, Daniel Gustafsson wrote:
Attached is a v2 which retains the sslcompression parameter for backwards
compatibility.
And now a v3 which fixes an oversight in postgres_fdw as well as adds an SSL
TAP test to cover deprecated
> On 26 Feb 2021, at 20:34, Daniel Gustafsson wrote:
> Attached is a v2 which retains the sslcompression parameter for backwards
> compatibility.
And now a v3 which fixes an oversight in postgres_fdw as well as adds an SSL
TAP test to cover deprecated parameters.
--
Daniel Gustafsson
> On 26 Feb 2021, at 03:34, Michael Paquier wrote:
> There is just pain waiting ahead when breaking connection strings
> that used to work previously. A "while" could take a long time
> though, see the case of "tty" that's still around (cb7fb3c).
I see your tty removal from 2003, and raise you
s retained. An alternative could be to retain the
>>>> parameter but not act on it in order to not break scripts etc, but that
>>>> just
>>>> postpones the pain until when we inevitably do remove it.
>>>>
>>>> Thoughts? Any reason to keep su
On Mon, Feb 22, 2021 at 12:28 PM Daniel Gustafsson wrote:
>
> > On 22 Feb 2021, at 11:52, Magnus Hagander wrote:
> >
> > On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson wrote:
> >>
> >> A few years ago we discussed whether to disable SSL compression [0]
On Mon, Feb 22, 2021 at 12:27:38PM +0100, Daniel Gustafsson wrote:
> On 22 Feb 2021, at 11:52, Magnus Hagander wrote:
>> I think for libpq we want to keep the option for a while but making it
>> a no-op, to not unnecessarily break systems where people just upgrade
>> libpq, though. And document it
> On 22 Feb 2021, at 11:52, Magnus Hagander wrote:
>
> On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson wrote:
>>
>> A few years ago we discussed whether to disable SSL compression [0] which
>> ended
>> up with it being off by default combined with a recomme
On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson wrote:
>
> A few years ago we discussed whether to disable SSL compression [0] which
> ended
> up with it being off by default combined with a recommendation against it in
> the docs.
>
> OpenSSL themselves disabled SSL comp
A few years ago we discussed whether to disable SSL compression [0] which ended
up with it being off by default combined with a recommendation against it in
the docs.
OpenSSL themselves disabled SSL compression by default in 2016 in 1.1.0 with
distros often having had it disabled for a long while
Hi,
On 2018-04-02 12:46:25 -0400, Tom Lane wrote:
> It seemed like the attack you described wasn't all that dependent on
> whether the data is compressed or not: if you can see the size of the
> server's reply to "select ... where account_number = x", you can pretty
> well tell the difference betw
Hi,
On 2018-04-02 10:25:04 -0400, Robert Haas wrote:
> In general, I'd expect compressing data to be beneficial for the
> security of encryption because it should increase the entropy of the
> encrypted bytes, but obviously it's not hard to hypothesize cases
> where the opposite is true for one re
On Mon, Apr 02, 2018 at 12:46:25PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I agree the attack is less likely to be applicable in typical database
> > installations. I think we should move forward with considering protocol
> > compression proposals, but any final result should put a
On 4/2/18 12:46, Tom Lane wrote:
> Peter Eisentraut writes:
>> I agree the attack is less likely to be applicable in typical database
>> installations. I think we should move forward with considering protocol
>> compression proposals, but any final result should put a warning in the
>> documentat
Peter Eisentraut writes:
> I agree the attack is less likely to be applicable in typical database
> installations. I think we should move forward with considering protocol
> compression proposals, but any final result should put a warning in the
> documentation that using compression is potential
On 4/2/18 11:05, Robert Haas wrote:
> Ah. Yeah, that makes sense. Although to use PG as a vector, it seems
> like the attacker would need to the ability to snoop network traffic
> between the application server and PG. If both of those are
> presumably inside the bank's network and yet an attack
On Mon, Apr 2, 2018 at 10:52 AM, Peter Eisentraut
wrote:
> On 4/2/18 10:25, Robert Haas wrote:
>> As I understand it on a brief review of the Google search
>> results^W^W^Wliterature, the reason that was done was to prevent
>> things like the CRIME attack, which apparently involves Javascript
>> r
On 4/2/18 10:25, Robert Haas wrote:
> As I understand it on a brief review of the Google search
> results^W^W^Wliterature, the reason that was done was to prevent
> things like the CRIME attack, which apparently involves Javascript
> running in your browser from deducing information that it shouldn
On Wed, Mar 28, 2018 at 7:16 PM, Andres Freund wrote:
> +analysis of whether that's safe to do from a cryptographic POV. There's a
> reason compression has been disabled for just about all SSL/TLS libraries.
As I understand it on a brief review of the Google search
results^W^W^Wliterature, the r
On March 28, 2018 4:15:02 PM PDT, Peter Eisentraut
wrote:
>On 3/28/18 13:26, Konstantin Knizhnik wrote:
>> If SSL compression is deprecated, should we provide own compression?
>> I have implemented some prototype implementation of it (patch is
>attached).
>> I have
On 3/28/18 13:26, Konstantin Knizhnik wrote:
> If SSL compression is deprecated, should we provide own compression?
> I have implemented some prototype implementation of it (patch is attached).
> I have added compression=on/off parameter to connection string and -Z
> option to psql
news altogether.
Seems reasonable as far as it goes, but do we need to make corresponding
server-side changes?
We could add a setting to disable SSL compression on the server, as some
web servers have been doing, but the niche of version combinations where
that would be applicable seems pretty low.
ut do we need to make corresponding
server-side changes?
We could add a setting to disable SSL compression on the server, as some
web servers have been doing, but the niche of version combinations where
that would be applicable seems pretty low.
One of our customers was managed to improve speed
o make corresponding
> server-side changes?
We could add a setting to disable SSL compression on the server, as some
web servers have been doing, but the niche of version combinations where
that would be applicable seems pretty low.
--
Peter Eisentraut http://www.2ndQuadrant.c
On 3/11/18 12:07, Magnus Hagander wrote:
> I think it's worth mentioning in the docs around "it's now considered
> insecure" that it's still an option to use if compression is the main
> thing one is looking for, rather than security. As in, it doesn't make
> it any less secure than no ssl at all.
Peter Eisentraut writes:
> The change in the Debian package I found was to build without zlib at
> all. So no amount of turning it back on will help. Whereas the
> upstream change was just to make the default to be off. But anyway,
> this feature is clearly dying, so we probably shouldn't be tr
On Sun, Mar 11, 2018 at 2:05 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/11/18 04:00, Magnus Hagander wrote:
> > I am not talking about the OpenSSL disabling it. It was disabled on most
> > *distributions* years ago, long before that commit. Which is why I'm
> > still cu
entraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 42d7f920c2732b5ea47bffd7bc1dc03b36fb6d05 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sun, 11 Mar 2018 08:53:33 -0400
Subject: [PATCH] Set libpq sslcompression to
Sun, Mar 11, 2018 at 12:36 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/9/18 09:06, Magnus Hagander wrote:
> > What platform does that actually work out of the box on? I have
> > customers who actively want to use it (for compression, not security --
> > replication acro
On 3/9/18 09:06, Magnus Hagander wrote:
> What platform does that actually work out of the box on? I have
> customers who actively want to use it (for compression, not security --
> replication across limited and metered links), and the amount of
> workarounds they have to put in place OS level to
On 9 March 2018 at 14:17, Gasper Zejn wrote:
> On 09. 03. 2018 06:24, Craig Ringer wrote:
>
> I'm totally unconvinced by the threat posed by exploiting a client by
> tricking it into requesting protocol compression - or any other protocol
> change the client lib doesn't understand - with a connec
On Fri, Mar 9, 2018 at 3:06 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/8/18 14:23, Claudio Freire wrote:
> > On Thu, Mar 8, 2018 at 3:40 PM, Peter Eisentraut
> > wrote:
> >> It appears that SSL compression is nowadays deprecated as i
the connecting client in whatever manner they wish by sending
> any custom crafted messages they like.
>
If the attacker has access to client process or environment, he's
already won and this is not where the compression vulnerability lies.
CRIME and BREACH attacks with (SSL) compression a
On Thu, Mar 8, 2018 at 11:06 PM, Peter Eisentraut
wrote:
> On 3/8/18 14:23, Claudio Freire wrote:
>> On Thu, Mar 8, 2018 at 3:40 PM, Peter Eisentraut
>> wrote:
>>> It appears that SSL compression is nowadays deprecated as insecure.
>>> Yet, it is still enabled
On 9 March 2018 at 03:23, Claudio Freire wrote:
> On Thu, Mar 8, 2018 at 3:40 PM, Peter Eisentraut
> wrote:
> > It appears that SSL compression is nowadays deprecated as insecure.
> > Yet, it is still enabled by libpq by default, and there is no way to
> > disable it i
On 3/8/18 14:23, Claudio Freire wrote:
> On Thu, Mar 8, 2018 at 3:40 PM, Peter Eisentraut
> wrote:
>> It appears that SSL compression is nowadays deprecated as insecure.
>> Yet, it is still enabled by libpq by default, and there is no way to
>> disable it in the serv
On Thu, Mar 8, 2018 at 3:40 PM, Peter Eisentraut
wrote:
> It appears that SSL compression is nowadays deprecated as insecure.
> Yet, it is still enabled by libpq by default, and there is no way to
> disable it in the server. Should we make some changes here? Does
> anyone know mor
It appears that SSL compression is nowadays deprecated as insecure.
Yet, it is still enabled by libpq by default, and there is no way to
disable it in the server. Should we make some changes here? Does
anyone know more about this?
--
Peter Eisentraut http://www.2ndQuadrant.com
52 matches
Mail list logo
