On 21 April 2016 at 22:21, Andreas Karlsson wrote:
> Wouldn't such a solution be just as vulnerable to CRIME as TLS is? I
> thought the reason for removing compression from TLS is to discourage
> people from writing applications which are vulnerable to compression based
> attacks by not proving
On 21 April 2016 at 22:07, Tom Lane wrote:
>
> Yeah. I think this should definitely be in the list of things we want
> to add when we do the fabled 4.0 protocol revision (and, indeed, it's
> been in the above-cited list for awhile). Whether we've yet gotten to
> the point of having critical ma
On 04/21/2016 03:04 PM, Aleksander Alekseev wrote:
I guess since the usual answer for compression was "use what SSL
provides you for free", it's rather unlikely that someone bothered to
make a proxy just for that purpose, and really, a proxy is just
another moving part in your setup: not everyone
Craig Ringer writes:
> On 21 April 2016 at 14:19, Shay Rojansky wrote:
>> There are potentially huge bandwidth savings which could benefit both WAN
>> and non-WAN scenarios, and decoupling this problem from TLS would make it
>> both accessible to everyone (assuming PostgreSQL clients follow). It
On 21 April 2016 at 14:19, Shay Rojansky wrote:
> Does it make sense to you guys to discuss compression outside of TLS?
>
Yes.
> There are potentially huge bandwidth savings which could benefit both WAN
> and non-WAN scenarios, and decoupling this problem from TLS would make it
> both accessi
On Thu, Apr 21, 2016 at 3:17 PM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> > > or on Linux TCP/IP stack level.
> > >
> >
> > Yes, but if you want to have both compression and encryption it is
> > crucial to apply compression *before* encryption and I don't see how
> > this can happ
> > or on Linux TCP/IP stack level.
> >
>
> Yes, but if you want to have both compression and encryption it is
> crucial to apply compression *before* encryption and I don't see how
> this can happen with this approach.
If I'm not mistaken IPSec gives you both compression and encryption.
Just as
On Thu, Apr 21, 2016 at 3:04 PM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> > I guess since the usual answer for compression was "use what SSL
> > provides you for free", it's rather unlikely that someone bothered to
> > make a proxy just for that purpose, and really, a proxy is jus
> I guess since the usual answer for compression was "use what SSL
> provides you for free", it's rather unlikely that someone bothered to
> make a proxy just for that purpose, and really, a proxy is just
> another moving part in your setup: not everyone will be thrilled to
> add that.
It just doe
On Thu, Apr 21, 2016 at 11:07 AM, Aleksander Alekseev <
a.aleks...@postgrespro.ru> wrote:
> > Does it make sense to you guys to discuss compression outside of TLS?
> > There are potentially huge bandwidth savings which could benefit both
> > WAN and non-WAN scenarios, and decoupling this problem f
> Does it make sense to you guys to discuss compression outside of TLS?
> There are potentially huge bandwidth savings which could benefit both
> WAN and non-WAN scenarios, and decoupling this problem from TLS would
> make it both accessible to everyone (assuming PostgreSQL clients
> follow). It wo
I know this has been discussed before (
http://postgresql.nabble.com/Compression-on-SSL-links-td2261205.html,
http://www.postgresql.org/message-id/BANLkTi=Ba1ZCmBuwwn7M1wvPFioT=6n...@mail.gmail.com),
but it seems to make sense to revisit this in 2016.
Since CRIME in 2012, AFAIK compression with en
12 matches
Mail list logo