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

Martin Rex <mrex@sap.com> Fri, 12 November 2010 03:34 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F5A3A691B for <tls@core3.amsl.com>; Thu, 11 Nov 2010 19:34:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level:
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oigXUFq8j1L for <tls@core3.amsl.com>; Thu, 11 Nov 2010 19:34:40 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A0FDE3A67E7 for <tls@ietf.org>; Thu, 11 Nov 2010 19:34:39 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id oAC3ZAvh014891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Nov 2010 04:35:10 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201011120335.oAC3Z9Lg005026@fs4113.wdf.sap.corp>
To: mike-list@pobox.com
Date: Fri, 12 Nov 2010 04:35:09 +0100
In-Reply-To: <4CDC76B4.6030803@pobox.com> from "Michael D'Errico" at Nov 11, 10 03:05:24 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Nov 2010 03:34:40 -0000

Michael D'Errico wrote:
> 
> Martin Rex wrote:
> > 
> > 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.
> 
> I guess it depends on what you consider "huge."  My server issues
> session tickets that are between about 230 and 260 bytes.  If a
> client certificate is negotiated, then this figure rises due to
> the fact that the certificate needs to be included in the ticket,
> but nobody uses them anyway (not trying to start a war :-)

With such a small session state, *I* would never worry about
offloading.  Unless one is using a very ill-suited load-balancing
technology, the servers should handle such lightweight
TLS session sizes with ease.  (The memory footprint for cached
session in our servers is _MUCH_ larger, and we would rather
shorten the cache lifetime than offloading (and the first choice
for offloading would be some compressed local storage that
works completely independent and for all tls clients anyway). 


I would be very interestend in TLS connection characteritics
and session characteristics (full-HS/resume ration for
numerous combinations of cache sizes and cache lifetimes) 
for Servers where TLS session tickets could make any sense
at all.



When refering to offloading between requests to the client,
I was thinking more about off-loading the _entire_ backend state
along with the TLS session state, which may amount many kilobytes
up to several megabytes.

When you're doing plain HTTP, a reverse-proxy load balancer
can look at the entire request headers to select the correct
backend for the request (so that no backend state needs to
be carried around).  But that option is no longer available
when the entire traffic is TLS-encrypted end-to-end, because
the load-balancer can no longer see the request headers that
it has been using all the time.

Load-balancing based on SSL session ID is not "reliable",
because there is only a likelyhood that it will be reused often,
but no assurance whatsoever that all communication that is
referencing this backend state will use only one single
SSL session ID and remain valid for as long as the backend
state is valid.

So that leaves you with the only option to terminate
the SSL communication with the frontends on the reverse
proxy to be able to look at all of the request headers
again and perform load balancing as before.  Depending
on what software you use and whether you want SSL re-encryption
between reverse proxy and backends, e.g. to perform
"authentication forwarding" of client certs, then
you might encounter performance issues.


Apache as SSL-terminating reverse proxy with SSL-reencryption to the
backend and _default_ configuration used to be a huge performance
problem--no HTTP/1.1 keep-alive combined with no client-side
SSL session caching towards the backend.  And while you can
enable the former (keep-alive) by configuration, client-side
SSL session caching has not been available in the past
(and maybe still isn't) in mod_proxy.


And when the SSL-renecrypted link (using SSL client certs) is
using certs from deep CA-hierarchies with aggressive revocation
options and a similarily aggressive PKI software in the TLS stack,
this can also significantly impair performance.
Some years ago I had a customer seriously suffering with such
certs in use between his BigIP/F5 loadbalancer and our backends.
Looking at the timing between SSL API calls within our
backend for a couple of requests and looking at the certificate
chains of both peers, I suggested him to remove that PKIX-nonsense
from his point-to-point links and the problems disappeared.


-Martin