From: dave.thompson2@verizon.net   
      
   On Sat, 7 Nov 2009 17:20:12 -0500, "barcaroller"   
    wrote:   
      
   >   
   > The TLS RFC refers to _multiple_ TCP/IP connections per SSL session.  Does   
   > this mean that an SSL session can have multiple (simultaneous) TCP   
   > connections going in parallel or does it simply mean that an SSL session can   
   > have multiple, sequential (resumed) TCP connections, one at a time?   
   >   
   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.   
      
   > It is my understanding that an SSL session applies to one source IP/port   
   > pair and one destination IP/port pair, so I'm inclined to lean towards the   
   > latter.   
   >   
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)