Re: [HACKERS] Speed of SSL connections; cost of renegotiation - Mailing list pgsql-interfaces

From Tom Lane
Subject Re: [HACKERS] Speed of SSL connections; cost of renegotiation
Date
Msg-id 11759.1050074673@sss.pgh.pa.us
Whole thread Raw
Responses Re: [HACKERS] Speed of SSL connections; cost of renegotiation
List pgsql-interfaces
"scott.marlowe" <scott.marlowe@ihs.com> writes:
> Ummm.  I'm not comfortable with using a time based period for 
> renogatiation.  What can move in an hour from a P100 on Arcnet versus a 32 
> CPU altix on switched fabric are two entirely different things.  If there 
> is a "sweet spot" for how often to renogotiate it would be based on 
> amount.

That's what I would think, too.  So we already have the right mechanism,
it's just a question of what the setting ought to be.

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).

So a too-short renegotiation interval is not only expensive time-wise,
but could actually be a net loss for security.

I'm beginning to think we need to consult some experts to find out what
the right tradeoff is.
        regards, tom lane

PS: the sshd setting that was quoted refers to how often a new server
key is chosen, which is really independent of choosing new session keys.
Does our SSL code even have the facility to choose new server keys?
If not, perhaps someone had better add it.



pgsql-interfaces by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: export to excel format
Next
From: Curt Sampson
Date:
Subject: Re: [HACKERS] Speed of SSL connections; cost of renegotiation