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 added compression=on/off para
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 and pgbench util
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
(PGconn *conn)
SSL_set_verify(conn->ssl, SSL_VERIFY_PEER, verify_cb);
/*
-* If the OpenSSL version used supports it (from 1.0.0 on) and the user
-* requested it, disable SSL compression.
+* Set compression option if the OpenSSL version used supports it (from
+
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 insecure.
> >> Yet, it is still enabl
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 connection
> option in PGOPTIONS or the "options" connstr
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 by libpq by default, and there is no
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 in the server. Should we ma
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 server. Should we make some change
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 more about this?
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/
Pos
28 matches
Mail list logo
