Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group