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
- [TLS] Security concerns around co-locating TLS an… Magnus Westerlund
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Paul Hoffman
- Re: [TLS] Security concerns around co-locating TL… Magnus Westerlund
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Geoffrey Keating
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Richard Hartmann
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Richard Hartmann
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Bill Frantz
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Bill Frantz
- Re: [TLS] Security concerns around co-locating TL… Steingruebl, Andy
- Re: [TLS] Security concerns around co-locating TL… t.petch
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… t.petch
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Yoav Nir
- Re: [TLS] Security concerns around co-locating TL… Nelson B Bolyard
- Re: [TLS] Security concerns around co-locating TL… Peter Saint-Andre
- Re: [TLS] Security concerns around co-locating TL… Bill Frantz
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Juho Vähä-Herttua
- Re: [TLS] Security concerns around co-locating TL… Juho Vähä-Herttua
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Nikos Mavrogiannopoulos
- Re: [TLS] Security concerns around co-locating TL… t.petch
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Michael D'Errico
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Martin Rex
- Re: [TLS] Security concerns around co-locating TL… Chris Newman
- Re: [TLS] Security concerns around co-locating TL… Nico Williams
- Re: [TLS] Security concerns around co-locating TL… Matt DeMoss
- Re: [TLS] Security concerns around co-locating TL… Yoav Nir
- Re: [TLS] Security concerns around co-locating TL… Joe Touch