Re: Speed of SSL connections; cost of renegotiation - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: Speed of SSL connections; cost of renegotiation
Date
Msg-id 1050031682.69328.40.camel@jester
Whole thread Raw
In response to Speed of SSL connections; cost of renegotiation  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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
hashedwith the  session's master_secret. Provided that the master_secret has not been  compromised and that the secure
hashoperations used to produce the  encryption keys and MAC secrets are secure, the connection should be  secure and
effectivelyindependent from previous connections.  Attackers cannot use known encryption keys or MAC secrets to
compromisethe 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
havebeen compromised,  or that certificates may have expired or been revoked, it should  force a full handshake. An
upperlimit of 24 hours is suggested for  session ID lifetimes, since an attacker who obtains a master_secret  may be
ableto 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

pgsql-hackers by date:

Previous
From: Sean Chittenden
Date:
Subject: Re: Speed of SSL connections; cost of renegotiation
Next
From: Alice Lottini
Date:
Subject: Integration with Access Method interface