X-Original-To: pgsql-hackers@postgreSQL.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 1CD12475B47; Thu, 10 Apr 2003 21:16:13 -0400 (EDT) Received: from perrin.int.nxad.com (internal.ext.nxad.com [69.1.70.251]) by postgresql.org (Postfix) with ESMTP id 612DF474E42; Thu, 10 Apr 2003 21:16:12 -0400 (EDT) Received: by perrin.int.nxad.com (Postfix, from userid 1001) id AEFB42105F; Thu, 10 Apr 2003 18:15:57 -0700 (PDT) Date: Thu, 10 Apr 2003 18:15:57 -0700 From: Sean Chittenden To: Tom Lane Cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org Subject: Re: Speed of SSL connections; cost of renegotiation Message-ID: <20030411011557.GJ79923@perrin.int.nxad.com> References: <7334.1050015002@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7334.1050015002@sss.pgh.pa.us> User-Agent: Mutt/1.4i X-PGP-Key: finger seanc@FreeBSD.org X-PGP-Fingerprint: 3849 3760 1AFE 7B17 11A0 83A6 DD99 E31F BC84 B341 X-Web-Homepage: http://sean.chittenden.org/ X-Spam-Status: No, hits=-37.8 required=5.0 tests=BAYES_10,IN_REP_TO,PATCH_UNIFIED_DIFF,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/343 X-Sequence-Number: 37833 > So, questions for the group: where did the decision to renegotiate > every 64K come from? Do we need it at all? Do we need it at such a > short interval? And if we do need it, shouldn't the logic be > symmetric, so that renegotiations are forced during large input > transfers as well as large output transfers? It doesn't look like there's any guidance from mod_ssl in Apache 2.0. http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_kernel.c?rev=1.92&content-type=text/vnd.viewcvs-markup 'round line 536 begins a good set of comments, but I think the tail end of the file has the best commentary: * Because SSL renegotations can happen at any time (not only after * SSL_accept()), the best way to log the current connection details is * right after a finished handshake. I think the correct solution to this is to have some way of specifying this via libpq or by some external configuration file as it is supposed to conform to the client or server's security policy. It'd say by default that 640K is ok, but that it should be tunable and apart of the connections properties. Ex: Index: libpq-fe.h =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/interfaces/libpq/libpq-fe.h,v retrieving revision 1.91 diff -u -r1.91 libpq-fe.h --- libpq-fe.h 2003/03/25 02:44:36 1.91 +++ libpq-fe.h 2003/04/11 01:12:32 @@ -154,6 +154,9 @@ * Password field - hide value "D" Debug * option - don't show by default */ int dispsize; /* Field size in characters for dialog */ +#ifdef USE_SSL + int ssl_reneg_size; /* Rate at which the connection renegotiates keys */ +#endif } PQconninfoOption; /* ---------------- Someone on IRC suggested that this value be tuned automatically depending on the cypher used. The more secure the cypher, the less frequently rekeying is needed. DES = 64K, 3DES = 256K, AES = 512K? Total WAG on the values there, but it conveys the point. -sc -- Sean Chittenden