Subject: Re: [TLS] SSL session caching & lookups

From: Yoav Nir <[email-masked]>
Date: Fri, 1 Feb 2008 11:56:07 +0200

If you have several servers with DNS load balancing, are the sessions  
actually synchronized between the servers?  Can you set up a session  
with server A and then resume it on B?

If the answer is no, then it makes sense to consider server IP. If the  
answer is yes, it doesn't.

I would like to point out two things, however:

1. Trying to resume a session is essentialy non-cost to the client, so  
why not attempt to resume all the time, even if only the DNS name  
matches?

2. Clients tend to cache DNS results, so even if you have DNS load  
balancing, a client will usually go to the same IP address again and  
again. If you have some other kind of load balancing that keeps a  
constant IP address, then you might have this problem.

On Feb 1, 2008, at 4:30 AM, Nagendra Modadugu wrote:

> I'd like to get some implementation advice about a matter that is not
> covered in the spec.
>
> NSS clients currently only attempt to resume a session if the
> following fields match:
> * server IP
> * server Port
> * session ID
> * server hostname
>
> Looking up sessions in this manner means that dns-load-balancing
> breaks SSL resumes.  Is there a case for checking server IP and port?
>
> nagendra
> _______________________________________________
> TLS mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/tls
>
> Scanned by Check Point Total Security Gateway.
>

_______________________________________________
TLS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Fri, 1 Feb 2008 15:24:08 +0100 (MET)

> NSS clients currently only attempt to resume a session if the

That are the three parameters that we use in our clients in order
to try an SSL session resume.  When client-side Proxies are involved,
then the server IP alone is insufficient (it would be fairly constant).

> * session ID

I don't know what you mean by listing "session ID".
An SSL session resume can only be proposed by a client, not by the
server.  The server can only agree to resume.  So the above three
parameters are the lookup key into the client side SSL session
cache -- the session ID is an attribute of the session itself.

-Martin