SSL/TLS question...
barcaroller
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?
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.
EJP
> Does
> this mean that an SSL session can have multiple (simultaneous) TCP
> connections going in parallel
Yes.
> or does it simply mean that an SSL session can
> have multiple, sequential (resumed) TCP connections, one at a time?
Again yes.
> It is my understanding that an SSL session applies to one source IP/port
> pair and one destination IP/port pair
No.
David Thompson
<barca...@music.net> 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.
barcaroller
"David Thompson" <dave.th...@verizon.net> 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.