From: barcaroller@music.net   
      
   "David Thompson"  wrote:   
      
   > Both, but in my experience more commonly the latter.   
   >   
   > An SSL/TLS 'session' saves the (negotiated) crypto settings. So e.g.   
   > you do one connection, do the relatively expensive and slow key   
   > establishment and usually authentication (RSA or DH or ECDH possibly   
   > plus DSA or ECDSA), then send and/or receive data, and disconnect;   
   > then connect again and quickly continue to send and/or receive data,   
   > or overlapping the original to quickly send/receive other data.   
   >   
   > Subject to any limitations either system (but usually the server)   
   > imposes on how much resources a given partner is allowed to use.   
   > And possibly the limitations on how much data should be protected with   
   > one set of DEKs before rekeying, which in SSL/TLS is renegotiation.   
   >   
   > Especially with HTTP/1.0 which (officially) required separate TCP   
   > connection per transaction=resource this was a pretty big win.   
   >   
   > SSL/TLS connections within a session don't have to use the same TCP/IP   
   > parameters. The session is identified by an up-to-32-octet value   
   > assigned by the server. If a client having the session params, using   
   > any address and port, reaches a server, using any address and port,   
   > that has (or can get) the same session params, they can 'resume'.   
   > The useful case for this is failover or pooling. Of course you need to   
   > restrict it somehow; you don't want to allow security that was set-up   
   > for Alice to Bob to be used by Carol. You might *choose* to use it   
   > only for same addresses and maybe even ports for simplicity.   
      
   Thanks for the detailed info; it was very useful.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)