Re: Recent vendor SSL renegotiation patches break PostgreSQL

Поиск
Список
Период
Сортировка
От Michael Ledford
Тема Re: Recent vendor SSL renegotiation patches break PostgreSQL
Дата
Msg-id 8adf46ea1002030852w1250e47bu18055e49b2778a10@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Recent vendor SSL renegotiation patches break PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Recent vendor SSL renegotiation patches break PostgreSQL  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Renegotiation after X amount of data is the recommended method AFAIK,
> because it limits the volume of data available to cryptanalysis.
> What makes you think that elapsed time is relevant at all?
>
>                        regards, tom lane

You are correct. In that volume of data also matters. It depends on
what kind of attack you are trying to minimize here. In my particular
use case I fluctuate between idle and busy but mostly low bandwidth.

You have four different primary cases that you are possible:

1) timed method on an idle link (or low usage)
2) timed method on a busy link (or high usage)
3) data limit on an idle link (or low usage)
4) data limit on a busy link (or high usage)

The timed method is more optimal for case 1.
The data limit is more optimal for case 4.

Case 2 gives an attacker more data to do crypto-analysis.
Case 3 gives an attacker more time to work with the current secret key
on a live link.

Depending on your use case, being able to work with a live link is
worse than working with the data postmortem. There is I'm sure some
hybrid in the middle between these where optimal lives.

Michael


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Hot Standby and VACUUM FULL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Recent vendor SSL renegotiation patches break PostgreSQL