Re: [TLS] Security concerns around co-locating TLS and non-secure

[Martin Rex <[e-mail]>]

Martin Rex wrote:
> 
> Nicolas Williams wrote:
> > 
> > I suspect the issue is that session resumption is generally not feasible
> > due to a) lack of implementation of session resumption without
> > server-side state, b) the need to cluster services making it difficult
> > to share server-side session resumption state.  Which would mean that
> > every TLS connection involves public key operations.
> 
> For those services that use either a NAT or DNS-A-round-robin load
> balancing, TLS session caching might be an issue.  Especially
> when clients are still using HTTP 1.0 (i.e. no keep-alive), like
> when they're behind a proxy and use HTTP/1.0 by default for proxy
> traversal -- which appears to be the default for a certain (huge)
> installed base...
> 
> Trying to load off server state on the client as a TLS session cookie
> might not be a solution for many scenarios, because it is simply not
> available in many implementations and the server-side state might
> be "huge" whereas the communication frequency and message size
> might be tiny -- which easily results in a _magnitude_ higher load
> when switching from HTTP to HTTPS.


Btw. there are load balancers that can take the SSL session ID
into account when balancing load and ensure that requests with
the same SSL session ID end up at the same backend server,
which significantly improves the TLS session resume ratio.


When there are certain usage peaks on TLS servers, adequate session
cache size&lifetime management can make a huge difference.

If you have a server running with TLS that is hit by a lot of requests,
you probably want a high percentage of TLS session resumes on those
connections so that you do not max out on the CPU usage because
of the TLS handshakes.

When we had a customer with peak load problems several years ago
with the CPU load of his 8-way server at 90% and fairly disappointing
response times.  I looked at SSL session characteristics
and noticed a poor full-HS/resume ratio (6000:21 in 60 seconds),
indicating that our default session cache size and lifetime were
not adequate for that usage profile and that cache pruning
apparently didn't work (bug).  So I asked the customer to set a
larger tls session cache size and significantly reduce the
session cache lifetime, which resulted in a much better
full-HS/resume ratio (183:9168 in 120 seconds) and the CPU
load of his server dropped back to 15% and the response times
were _much_ better.  On a busy server, a server-side TLS session
cache lifetime in the area of 15-30 minutes is just fine to keep
the CPU load at acceptable levels.

I haven't come around to write a code for an automatic dynamic
cache size&lifetime adjustment depending on the server's
load and usage patterns.  The way how OpenSSL manages cache
lifetime might not be useful for such management, because
rather than session creation time, OpenSSL calculates on session
creation when a session should be expired on current parameters
and only stores that time in the cache.  For dynamic adjustments
when the cache is close to full, I prefer to have cache lifetime
adjustments affect all cache contents immediately based on the
true session age, not just new sessions (for which there is
not much room left).

-Martin