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

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> - what do you mean by expensive?  Google has published research results
> showing that enabling TLS on their services required no more/different
> hardware than they were using prior to switching on TLS.

They were probably comparing apples and oranges plus their specific
application is absolutely no indicator how much of an impact this
would have on _other_ applications.

When I heard this the first time, I quickly tried searching via
the orange https://www.google.com and immediately noticed the
difference to the Web-2.0 http://www.google.com apple that
ping-pongs every keypress.


> 
> > The figure I heard second-hand from some large non-financial web
> > sites that use TLS for logon, but then switch back to HTTP for the
> > rest of the session (and thus have been subject to the FireSheep
> > plugin) is that keeping TLS on for the whole session would increase
> > the size of their server farm by 10%. I find it incredible that e.g.
> > RC4 + HMAC would add 10% in this day of multi-core, but there you
> > have it.
> 
> 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.


Another issue might be poor application design -- which is not
necessarily obvious to "apps folks", when the server app is
performing HUGE amounts of small network writes, but didn't
use setsockopt(TCP_NODELAY) -- so that the Nagle algorithm
has been covertly easing the resulting pain for the network.


If such an app or web server plugin is suddenly called over TLS/HTTPS,
the performance impact as well as the increase in network bandwidth
might be even more than the order of one magnitude, because most SSL
APIs will produce SSL records for every single write call.
I've seen that happening -- and was disappointed how painful
and slow the education of application programmers progressed
in paying more attention to such design issues and fixing them.

In the case I encountered, it was a Microsoft IIS plugin producing
a dynamic HTML page full of javascript with context-sensitive contents
of drop-down boxes.  Originally the IIS reply was 97 distinct
SSL records to deliver only 3500 bytes.  After educating the
apps developers and fixing the app, the exact record boundaries
and number of records varied, 25-27 distinct records for 3500 bytes,
a fragmentation that seemed to be caused by IIS itself.


I've recently encountered similarily questionable behaviour
from a smartphone app, where a _picture_ upload to a TLS server
uses SSL records with 1320 bytes max.  That is the kind of
stuff that impacts your server's performance by more than 10%.


-Martin