> On Mar 12, 2017, at 7:23 PM, Ivan Ristic <ivan.ris...@gmail.com> wrote:
>
> Another example, perhaps relevant: load balancers can often be configured to
> use sticky sessions based on TLS session IDs. It's a useful feature given
> that web servers typically don't have a good story for distributed
> server-side TLS session storage. Without an explicit ID, they too would need
> to make their own.
With session tickets, there's no need for server-side TLS session storage,
and no need for load-balancers to direct resuming TLS clients to the same
server. All that's required is proper coordination of the distribution
and rotation of the short-term session ticket encryption keys. This
improves the effectiveness of the load-balancer when some clients are
responsible for a large fraction of the load.
Opaque session tickets are just fine, and one can tell which connections
are reused by observing abbreviated handshakes.
For example, Gmail's SMTP servers all share the same session ticket encryption
keys, and any server can resume a session initiated by a different server.
Here's an example, in which an SMTP TLS client reuses a session with a
second Gmail SMTP server (w51si13238472qtb.292) 10 seconds after the
session is created with a first SMTP server (r3si13266009qkb.62):
$ posttls-finger -lmay -Lcache,summary -m 3 -r 10 gmail.com
posttls-finger: Connected to gmail-smtp-in.l.google.com[209.85.144.27]:25
posttls-finger: < 220 mx.google.com ESMTP r3si13266009qkb.62 - gsmtp
posttls-finger: > EHLO straasha.imrryr.org
posttls-finger: < 250-mx.google.com at your service, [108.21.89.116]
...
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: looking for session
[209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16
in memory cache
posttls-finger: save session
[209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16
to memory cache
posttls-finger: Untrusted TLS connection established to
gmail-smtp-in.l.google.com[209.85.144.27]:25: TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
posttls-finger: > EHLO straasha.imrryr.org
posttls-finger: < 250-mx.google.com at your service, [108.21.89.116]
...
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 closing connection r3si13266009qkb.62 - gsmtp
posttls-finger: Reconnecting after 10 seconds
<...10 second delay...>
posttls-finger: < 220 mx.google.com ESMTP w51si13238472qtb.292 - gsmtp
posttls-finger: looking for session
[209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16
in memory cache
posttls-finger: reloaded session
[209.85.144.27]:25&8A8ACB9F076F21BB0182A29964626E9B9E564450364F42705D3248594EF24C16
from memory cache
posttls-finger: gmail-smtp-in.l.google.com[209.85.144.27]:25: Reusing old
session
posttls-finger: Untrusted TLS connection established to
gmail-smtp-in.l.google.com[209.85.144.27]:25: TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 closing connection w51si13238472qtb.292 - gsmtp
posttls-finger: Found a previously used server. Done reconnecting.
--
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
