Re: [HACKERS] Wire protocol compression

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 >

Re: [HACKERS] Wire protocol compression

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

Re: [HACKERS] Wire protocol compression

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

Re: [HACKERS] Wire protocol compression

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

Re: [HACKERS] Wire protocol compression

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

Re: [HACKERS] Wire protocol compression

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

Re: [HACKERS] Wire protocol compression

> > 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

Re: [HACKERS] Wire protocol compression

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

Re: [HACKERS] Wire protocol compression

> 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

Re: [HACKERS] Wire protocol compression

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

Re: [HACKERS] Wire protocol compression

> 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

[HACKERS] Wire protocol compression

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