Re: [TLS] Security concerns around co-locating TLS and non-secure
Martin Rex <mrex@sap.com> Wed, 10 November 2010 03:24 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066E33A67F3; Tue, 9 Nov 2010 19:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.817
X-Spam-Level:
X-Spam-Status: No, score=-9.817 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_BIZOP=0.7]
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 bx+DflUOBW2a; Tue, 9 Nov 2010 19:24:53 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id C612A3A67AE; Tue, 9 Nov 2010 19:24:52 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id oAA3PFWd018016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Nov 2010 04:25:16 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201011100325.oAA3PEBB021028@fs4113.wdf.sap.corp>
Subject: Re: [TLS] Security concerns around co-locating TLS and non-secure
To: marsh@extendedsubset.com
Date: Wed, 10 Nov 2010 04:25:14 +0100
In-Reply-To: <4CD98A16.4070004@extendedsubset.com> from "Marsh Ray" at Nov 9, 10 11:51:18 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal04
X-SAP: out
X-Mailman-Approved-At: Fri, 12 Nov 2010 08:06:55 -0800
Cc: paul.hoffman@vpnc.org, tls@ietf.org, tsvwg@ietf.org, Nicolas.Williams@oracle.com
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2010 03:24:54 -0000
Marsh Ray wrote: > > > SSH has been so successful in large part because leap-of-faith works > > rather well -- it has a very small window of vulnerability, a very big > > vulnerability, yes, and requiring persistent storage, true, but > > difficult to exploit without users eventually noticing. > > I know I read a study somewhere of what users (a university setting I > think) typically did when presented with the "WARNING: REMOTE HOST > IDENTIFICATION HAS CHANGED!...Are you sure you want to continue > connecting (yes/no)?" question. I think the results were pretty dismal. How surprising. If you furnish your users with software that will perform a social engineering attack on your users whenever an outside attacker asks for it, why should you expect a different reaction? (btw. the SSH clients that I'm using do not suggest to override a changed host key and in particular don't offer to do so with a simple "Y" keypress, they just fail.) Curiosity kills cats and makes social attacks succeed. If you send an intriguing Email with a dangerous attachment to a significantly large fraction of employees in a company, _some_ of the users _will_ double-click the attachment -- guaranteed. For something that sounds moderately interesting it may be around ~10% of the recipients blindly relying on the safety of the AV-software to protect them from dangerous stuff. The underlying problem with the "TLS PKI" is that it is an ants-level solution to ant-level problems. "Smells like its from our nest -- just let it in". Evolution caused more advanced species to use more sophisticated schemes of trust and protection against impersonation, and I really do not understand why there is so much resistance against evolving TLS security beyond ants level. All trust decisions performed by more advanced species are based on leap-of-faith on initial encounter and memorizing information for validating future encouters of the same individuals (and things), including recognizing ones parents. Personally, I find it frightening just how wildly successful a tool like Firesheep is in attacking services like GoogleMail, Hotmail, Facebook, ebay and sorts. If the services themselves already subvert the security so throughly by doing parts or most of the communication totally unprotected, then it seems pretty pointless to discuss the (lack of) value of the commercial CA TLS PKI. For a number of "selling" players around the TLS technology, the most interesting part appears to be the business models / business opportunities, not the security. And for a number of "consumers" of the TLS technology the most appealing part is continuity in authenticating end users with weak passwords. > > So, except in cases where explictly unauthenticated endpoints are > involved, isn't it reasonable that for WG discussions to presume that a > security protocol will be building upon some form of trust framework? There will always be both. Starting from scratch with no trust framework, and integrating into an existing trust framework (personal, home/family, organizational/corporate or governmental). > > Or is there a new world happening where we're retreating from that > principle and we now expect systems to somehow bootstrap their own > security out-of-the-box or not get used at all? There are out-of-band key distribution & personalization schemes, One that is being used quite heavily around the globe is distribution "SIM" cards. Another one is TPM modules. Or smartcards containing public key crypto and credentials. The most popular schemes are "bootstrapping" with leap-of-faith, and bootstrapping with (simple|default|anything) passwords. And "thanks to TLS" traffic encryption, password based authentication schemes will be with us for very much longer... -Martin
- Security concerns around co-locating TLS and non-… Magnus Westerlund
- 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… Michael D'Errico
- Re: Security concerns around co-locating TLS and … Geoffrey Keating
- 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… 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… Marsh Ray
- 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… 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… Nicolas Williams
- 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… Nicolas Williams
- 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… 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… Nicolas Williams
- Re: [TLS] Security concerns around co-locating TL… Marsh Ray
- Re: [TLS] Security concerns around co-locating TL… Matt DeMoss
- Re: [TLS] Security concerns around co-locating TL… Nico Williams
- Re: [TLS] Security concerns around co-locating TL… Chris Newman
- Re: [TLS] Security concerns around co-locating TL… Yoav Nir
- Re: [TLS] Security concerns around co-locating TL… Joe Touch