Re: Speed of SSL connections; cost of renegotiation

Rod Taylor <rbt@rbt.ca>

From: Rod Taylor <rbt@rbt.ca>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>, pgsql-interfaces@postgresql.org
Date: 2003-04-11T03:28:02Z
Lists: pgsql-hackers
> It looks to me like the culprit is SSL renegotiation.  The server is
> currently programmed to force a renegotiation after every 64K of data
> transferred to or from the client.  However, the test to decide to do
> a renegotiation was placed only in SSL_write, so a large COPY-to-server
> escapes triggering the renegotiation except at the very end, whereas the
> COPY-to-file case is indeed executing a renegotiation about every 64K.
> Apparently, those renegotiations are horridly expensive.

BEA has a configuration parameter (ISL -- Interval for Session
Renogiation) allowing you to specify the frequency in whole minutes. 
The default being 0, or disabled renegotiations.



http://www.ietf.org/rfc/rfc2246.txt

Dealing with session ID:

F.1.4. Resuming sessions

   When a connection is established by resuming a session, new
   ClientHello.random and ServerHello.random values are hashed with the
   session's master_secret. Provided that the master_secret has not been
   compromised and that the secure hash operations used to produce the
   encryption keys and MAC secrets are secure, the connection should be
   secure and effectively independent from previous connections.
   Attackers cannot use known encryption keys or MAC secrets to
   compromise the master_secret without breaking the secure hash
   operations (which use both SHA and MD5).

   Sessions cannot be resumed unless both the client and server agree.
   If either party suspects that the session may have been compromised,
   or that certificates may have expired or been revoked, it should
   force a full handshake. An upper limit of 24 hours is suggested for
   session ID lifetimes, since an attacker who obtains a master_secret
   may be able to impersonate the compromised party until the
   corresponding session ID is retired. Applications that may be run in
   relatively insecure environments should not write session IDs to
   stable storage.



http://www.ssl-technology.com/ssl_persistence.htm

It looks like IEv5 (and up) will renegotiate the Session ID every 2
minutes:

"Beginning with IE5, Microsoft changed the behavior of their secure
channel libraries to force a renegotiation of a new SSL session every
two minutes. This meant that all IE5+ users would change SSL Session ID
every two minutes, breaking the only method of secure persistence
available."
-- 
Rod Taylor <rbt@rbt.ca>

PGP Key: http://www.rbt.ca/rbtpub.asc