Re: disable SSL compression?
От | Garick Hamlin |
---|---|
Тема | Re: disable SSL compression? |
Дата | |
Msg-id | 20180402174843.GA19621@isc.upenn.edu обсуждение исходный текст |
Ответ на | Re: disable SSL compression? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, Apr 02, 2018 at 12:46:25PM -0400, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> 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 potentially insecure. > > It seemed like the attack you described wasn't all that dependent on > whether the data is compressed or not: I think it is. I wrote something longer about this in 2013. https://www.postgresql.org/message-id/20130115172253.GA6662@isc.upenn.edu The key idea is you can now to a radix search of a secret rather than a single 1-bit match/doesn't match oracle type attack which is not feasible when you have an high entropy low density value like a big ascii number or hex string. I do something like set my preferred email (or anything an application lets a user change) to something like a3bf and keep extending the guess as I go and sometimes I compress along with the secret and rather than have to guess a whole application session id all at once and have a work factor of O(2^128) or something I've got a very tractable search. It might not be something that a problem for everyone, but in some situations it's attackable. Garick
В списке pgsql-hackers по дате отправления: