Re: [HACKERS] Speed of SSL connections; cost of renegotiation
От | Curt Sampson |
---|---|
Тема | Re: [HACKERS] Speed of SSL connections; cost of renegotiation |
Дата | |
Msg-id | Pine.NEB.4.51.0304121258300.624@angelic-vtfw.cvpn.cynic.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Speed of SSL connections; cost of renegotiation (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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. Well, I suspect that the amount is high enough that you might leave a connection from, say, a web server using the same key for days on end if you set a reasonably high amount. Probably the ideal is to have a maximum time and amount. But as you point out, if it's a GUC variable, it can be set by the user. Personally, I would tend to go for a time limit over a size limit because a size limit leaves an open-ended time, whereas a time limit puts a definite limit on size as well. (And a very powerful system going full bore for a long period of time over a high-speed connection is pretty rare.) 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. > I'm beginning to think we need to consult some experts to find out what > the right tradeoff is. If you really want to know, yes. I would think there would be a paper or something out there, but I failed to dig one up. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
В списке pgsql-interfaces по дате отправления: