Re: Speed of SSL connections; cost of renegotiation

From: Rod Taylor <rbt(at)rbt(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Speed of SSL connections; cost of renegotiation
Date: 2003-04-11 03:28:02
Message-ID: 1050031682.69328.40.camel@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces


> 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(at)rbt(dot)ca>

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tony Reina 2003-04-11 06:17:22 Does libpq have SSL functions?
Previous Message Sean Chittenden 2003-04-11 03:22:42 Re: Speed of SSL connections; cost of renegotiation

Browse pgsql-interfaces by date

  From Date Subject
Next Message Faizol Halim 2003-04-11 06:35:03 export to excel format
Previous Message Sean Chittenden 2003-04-11 03:22:42 Re: Speed of SSL connections; cost of renegotiation