Re: BUG #14329: libpq doesn't send complete client certificate chain on first SSL connection
От | Heikki Linnakangas |
---|---|
Тема | Re: BUG #14329: libpq doesn't send complete client certificate chain on first SSL connection |
Дата | |
Msg-id | 9859e5ae-d1fa-948a-c73e-6a7e3ccb5ccb@iki.fi обсуждение исходный текст |
Ответ на | BUG #14329: libpq doesn't send complete client certificate chain on first SSL connection (kzuk@akamai.com) |
Список | pgsql-bugs |
On 10/04/2016 10:53 PM, David Gould wrote: > On Tue, 4 Oct 2016 21:55:52 +0300 > Heikki Linnakangas <hlinnaka@iki.fi> wrote: > >> I'm starting to feel that using the same SSL_CTX object for multiple >> connections is just too fragile. Perhaps we could share one SSL_CTX >> object for all the connections with no sslcert and no sslrootcert, but >> I'm not sure if even that is worth it. >> >> In quick testing, calling SSL_CTX_new() for each connection adds about >> 3% of overhead to establishing a new connection, with the default >> OpenSSL settings (seems to use ECDHE-RSA-AES256-GCM-SHA384 cipher here). >> I also tested memory usage with a program that opens 10000 connections, >> and it used about 15% more memory, when SSL_CTX_new() is called for each >> connection. I think that's acceptable. Barring objections, I'm going to >> write a patch to use a separate SSL context for every connection. > > What about keeping a table of connection strings and SSL contexts so that all > connections using the same connection string could share the SSL context? It > seems likely that most applications reuse the same connection string and > could avoid the penalty. Yeah, could do that. Then again, I don't think it's worth the trouble. - Heikki
В списке pgsql-bugs по дате отправления: