Re: Speed of SSL connections; cost of renegotiation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Curt Sampson <cjs(at)cynic(dot)net>
Cc: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Speed of SSL connections; cost of renegotiation
Date: 2003-04-12 05:26:26
Message-ID: 16304.1050125186@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

Curt Sampson <cjs(at)cynic(dot)net> writes:
> On Fri, 11 Apr 2003, Tom Lane wrote:
>> I realized this morning that there's probably a security tradeoff
>> involved: renegotiating the session key limits the amount of session
>> data encrypted with any one key, which is good; but each renegotiation
>> requires another use of the server key, increasing the odds that an
>> eavesdropper could break *that* (which'd let him into all sessions not
>> just the one).

> This seems extremely low-risk to me; there's very little data
> transferred using the server key.

Perhaps, but the downside if the server key is broken is much worse
than the loss if any one session key is broken. Also, I don't know
how stylized the key-renegotiation exchange is --- there might be
a substantial known-plaintext risk there.

The fact that sshd thinks it necessary to choose a new server key as
often as once an hour indicates to me that they consider the risks
nonnegligible.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2003-04-12 06:41:35 OT: cvsup for Red Hat 9 or rsync cvs
Previous Message Curt Sampson 2003-04-12 04:05:05 Re: Speed of SSL connections; cost of renegotiation

Browse pgsql-interfaces by date

  From Date Subject
Next Message Greg Stark 2003-04-12 15:10:42 Re: Memory leak!!
Previous Message Curt Sampson 2003-04-12 04:05:05 Re: Speed of SSL connections; cost of renegotiation