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