From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dave Cramer <pg(at)fastcrypt(dot)com>, Edoardo Innocenti - SDB Information Technology Srl <edoardo(dot)innocenti(at)tech(dot)sdb(dot)it>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: JDBC compression over SSL |
Date: | 2015-01-09 03:25:02 |
Message-ID: | CAMsr+YFh1J72bckTZe0te+eJCJ=JnW-g-q_KQhFg_thVdxKxDw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 5 January 2015 at 23:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> > Yep... and I'm not sure it's actually doing SSL compression, rather than
> > compression of the stream *inside* the SSL socket.
>
> Worth noting here is that many/most people have abandoned use of SSL
> compression because it is now known to render the stream more
> decryptable. I do not know whether that objection also applies to
> doing separate compression "inside the socket" as you put it.
>
>
Whether or not it does, if it's not actual SSL compression it won't
interoperate with PostgreSQL - as you know, PostgreSQL doesn't support data
stream compression on the socket.
Some people are trying to use SSL compression as a workaround for this. I
think the real answer is probably to just add PostgreSQL protocol-level
support for compression, rather than trying to (ab)use SSL for it.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Juraj Bak | 2015-01-11 00:00:10 | JDBC createBlob implementation |
Previous Message | Vinayak | 2015-01-07 07:01:08 | Re: Problem with DATE |