Re: Recent vendor SSL renegotiation patches break PostgreSQL

From: Michael Ledford <mledford(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Date: 2010-02-03 16:52:08
Message-ID: 8adf46ea1002030852w1250e47bu18055e49b2778a10@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-02-03 16:58:36 Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous Message Tom Lane 2010-02-03 16:50:43 Re: Hot Standby and VACUUM FULL