[TLS] TLS, PKI, and web security. Was: Eleven out of every ten SSL certs aren't valid
Marsh Ray <marsh@extendedsubset.com> Fri, 02 July 2010 08:47 UTC
Return-Path: <marsh@extendedsubset.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 788153A685B for <tls@core3.amsl.com>; Fri, 2 Jul 2010 01:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.246
X-Spam-Level:
X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_50=0.001]
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 kHp-QXmIlQPj for <tls@core3.amsl.com>; Fri, 2 Jul 2010 01:47:17 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 0DAB63A67A5 for <tls@ietf.org>; Fri, 2 Jul 2010 01:47:17 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OUbuC-0008re-Lx; Fri, 02 Jul 2010 08:47:28 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3E0806332; Fri, 2 Jul 2010 08:47:26 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18pGliQ5XUd0U2SnA64a8ikCKD2E5SjDgY=
Message-ID: <4C2DA79B.9040500@extendedsubset.com>
Date: Fri, 02 Jul 2010 03:47:23 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
References: <E1OUXKw-0004cc-8W@wintermute02.cs.auckland.ac.nz>
In-Reply-To: <E1OUXKw-0004cc-8W@wintermute02.cs.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: [TLS] TLS, PKI, and web security. Was: Eleven out of every ten SSL certs aren't valid
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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, 02 Jul 2010 08:47:18 -0000
On 07/01/2010 10:54 PM, Peter Gutmann wrote: > > (I'm dreading someone asking "OK, list all these refs" because then > I'll have to go away and spend several hours digging them all up... > how many do people want before they say "OK, that's enough"?. > Cormac's paper has about eight, and that's barely scratching the > surface). I believe you - surely most people will click through most warnings most of the time. > No, it says that what we're doing doesn't work, has never worked, and > as far as anyone can tell will never work (and we have a > multibillion(?) dollar global cybercrime indistry to prove it), so > lets look for alternatives that do work. But still, most of those people lost their online banking credentials to the global cybercrime industry to a phishing email, because they use the same password everywhere, because their endpoint PC is owned by a keylogging botnet, or all of the above. They got this way by buying downloading commercial application software in brightly colored boxes, not keeping it up-to-date, and trusting a UI when it says "this executable is signed and has a shield icon, click OK to let it own your computer". They likely did not get owned by a MitM of their SSL/TLS connection where they clicked through a scary page. Some observations: 1. This is not evidence that "browser warnings are ineffective". If anything it shows that HTTPS is categorically better than most other parts of this system. 2. These users are completely incompetent relative to the impossibly hard job of keeping a general-purpose computer secure while consuming content from the hostile internet. (This is not to say anything bad about them, they are probably wiser for not wasting too much personal energy on managing data security.) It will be forever impossible to keep them "safe online", just like 200 years of experience in postal technology has not eliminated mail fraud. Therefore I strenuously object to this "least-common-denominator users confidently spending money online" model being allowed to drive the discussion of TLS. It is simply not possible to have a meaningful technical discussion about a cryptographic data security protocol unless we can agree that both Alice and Bob have a baseline of self-interest and competence to secure their endpoints. >Let's just admit > that what users are getting now is effectively unauth'd DH and then > try and give them something that actually works. No! Not this user, and not the systems I help to build and deploy. There are all kinds of interesting, embedded, automated, unattended, and large-scale systems successfully using TLS for securing critical data communications. More importantly, there _are_ careful and conscientious admins who do a totally professional job at maintaining their production systems according to recommended best practices. It is the requirements of this group that TLS must be optimized to meet. For if the competent professional cannot successfully employ the full security of this protocol, what chance does that leave for the typical user? Consider the biggest shift in data processing in decades is cloud computing. Cloud management and seemingly every piece of new networking gear presents a web-based admin UI for use with your ordinary browser. So the security of the apps, documents, servers, VPNs, and even big parts of the network itself has been rebuilt atop TCP port 443. This architecture self-organized due to powerful economic and social forces, not because anyone felt it was the best way from a security perspective. So we really have no choice but to get our protocol primitives nailed down air-tight: * Users must be informed of the essential role they have in the security architecture. They need to know a bit more of the mechanics of PKI in order to bring to bear the common sense that people are actually pretty good at. I suspect most people will take it seriously and can actually do a respectible job of it, just like most people understand not to use a hair dryer in the bathtub. Note that that little bit of user education cost neither bathtubs nor hair dryers any market share. * PKI built on the absolute trust of hundreds of omnipotent root certs from friend and foe alike just doesn't cut it any more. Vendors of the disintegrating status quo need to lead with some real improvements or embrace obsolescence. * Server admins need to be informed that HTTPS does not allow the server to prove the nonexistence of a MitM, the protocol relies on the client to do a good job of this. Therefore the server ends up having no choice but to transitively trust the union of all the sets of trusted root certs of all the clients that could be used to access the system. * TLS client certificate auth can allow the server to disprove the MitM. Web clients and servers should implement first-rate support for this configuration and provide integrated tools for users and admins to manage them. * A limited, securable subset of this insane layer cake of protocols we currently call "the web" needs to be precisely defined and adopted. Its use must become accepted as required best practice in security critical contexts, much like https has. It must include a browser security model with well-defined and strong boundaries. * Much as we once thought security would result naturally from a thorough analysis of functional requirements, current designs sometimes meet stated security goals yet have undesirable properties relating to expectations of privacy. Mechanisms for identifying and metadata tagging relevant information (as we may sometimes retain character data encoding information) and implementing data handling policies (much like database integrity constraints) should be standardized. * The identities of all parties contributing content, script, and cookies affecting the current page need to be prominently displayed and greatly restricted for secure systems. There may yet still be time to prevent your firewall's admin page from hosting web bugs for advertisers and participating in social networking mashups. Anyway, just some thoughts on things that could use improving. It seems like TLS itself is decent shape and is in a good position to expand its role in support of some larger goals. - Marsh
- Re: [TLS] Eleven out of every ten SSL certs aren'… aerowolf
- [TLS] Eleven out of every ten SSL certs aren't va… Peter Gutmann
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Martin Rex
- Re: [TLS] Eleven out of every ten SSL certs aren'… Adam Langley
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Tim Dierks
- Re: [TLS] Eleven out of every ten SSL certs aren'… Martin Rex
- Re: [TLS] Eleven out of every ten SSL certs aren'… Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] Eleven out of every ten SSL certs aren'… Rob P Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Joshua Davies
- Re: [TLS] Eleven out of every ten SSL certs aren'… Yoav Nir
- Re: [TLS] Eleven out of every ten SSL certs aren'… aerowolf
- Re: [TLS] Eleven out of every ten SSL certs aren'… Rob P Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nikos Mavrogiannopoulos
- Re: [TLS] Eleven out of every ten SSL certs aren'… Bill Daskaluk
- Re: [TLS] Eleven out of every ten SSL certs aren'… Tim Dierks
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Marsh Ray
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Tim Dierks
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Tim Dierks
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Marsh Ray
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Marsh Ray
- Re: [TLS] Eleven out of every ten SSL certs aren'… aerowolf
- Re: [TLS] Eleven out of every ten SSL certs aren'… Jeffrey A. Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Bruno Harbulot
- Re: [TLS] Eleven out of every ten SSL certs aren'… Bill Frantz
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Bruno Harbulot
- Re: [TLS] Eleven out of every ten SSL certs aren'… Peter Gutmann
- Re: [TLS] Eleven out of every ten SSL certs aren'… Peter Gutmann
- Re: [TLS] Eleven out of every ten SSL certs aren'… Marsh Ray
- Re: [TLS] Eleven out of every ten SSL certs aren'… Ivan Ristic
- Re: [TLS] Eleven out of every ten SSL certs aren'… Florian Weimer
- Re: [TLS] Eleven out of every ten SSL certs aren'… Peter Gutmann
- Re: [TLS] Eleven out of every ten SSL certs aren'… Bruno Harbulot
- Re: [TLS] Eleven out of every ten SSL certs aren'… Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] Eleven out of every ten SSL certs aren'… Martin Rex
- Re: [TLS] Eleven out of every ten SSL certs aren'… Steffen Schulz
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Martin Rex
- Re: [TLS] Eleven out of every ten SSL certs aren'… aerowolf
- Re: [TLS] Eleven out of every ten SSL certs aren'… aerowolf
- Re: [TLS] Eleven out of every ten SSL certs aren'… Marsh Ray
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Seth David Schoen
- Re: [TLS] Eleven out of every ten SSL certs aren'… Nicolas Williams
- Re: [TLS] Eleven out of every ten SSL certs aren'… Martin Rex
- Re: [TLS] Eleven out of every ten SSL certs aren'… Martin Rex
- Re: [TLS] Eleven out of every ten SSL certs aren'… =JeffH
- Re: [TLS] Eleven out of every ten SSL certs aren'… Peter Gutmann
- Re: [TLS] Eleven out of every ten SSL certs aren'… Peter Gutmann
- Re: [TLS] Eleven out of every ten SSL certs aren'… Peter Gutmann
- Re: [TLS] Eleven out of every ten SSL certs aren'… Steingruebl, Andy
- Re: [TLS] Eleven out of every ten SSL certs aren'… Peter Gutmann
- Re: [TLS] Eleven out of every ten SSL certs aren'… Steingruebl, Andy
- [TLS] TLS, PKI, and web security. Was: Eleven out… Marsh Ray
- Re: [TLS] Eleven out of every ten SSL certs aren'… Peter Gutmann
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Peter Gutmann
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Marsh Ray
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Robert Relyea
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Bruno Harbulot
- Re: [TLS] TLS, PKI, Martin Rex
- Re: [TLS] TLS, PKI, Robert Relyea
- Re: [TLS] TLS, PKI, Marsh Ray
- Re: [TLS] TLS, PKI, Martin Rex
- Re: [TLS] TLS, PKI, Peter Gutmann
- Re: [TLS] TLS, PKI, Peter Gutmann
- Re: [TLS] TLS, PKI, Marsh Ray
- Re: [TLS] TLS, PKI, Bruno Harbulot
- Re: [TLS] TLS, PKI, Peter Gutmann
- Re: [TLS] TLS, PKI, Yoav Nir
- Re: [TLS] TLS, PKI, Yoav Nir
- Re: [TLS] TLS, PKI, Peter Gutmann
- Re: [TLS] TLS, PKI, Peter Gutmann
- Re: [TLS] TLS, PKI, Bruno Harbulot
- Re: [TLS] TLS, PKI, Robert Relyea
- Re: [TLS] TLS, PKI, Marsh Ray
- Re: [TLS] TLS, PKI, Martin Rex
- Re: [TLS] TLS, PKI, Steingruebl, Andy
- Re: [TLS] TLS, PKI, Kyle Hamilton
- Re: [TLS] TLS, PKI, Marsh Ray
- Re: [TLS] TLS, PKI, Peter Gutmann
- Re: [TLS] TLS, PKI, Bruno Harbulot
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Peter Gutmann
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Marsh Ray
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Peter Gutmann
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Ralph Holz
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Yoav Nir
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Nasko Oskov
- Re: [TLS] TLS, PKI, Martin Rex
- Re: [TLS] TLS, PKI, Martin Rex
- Re: [TLS] TLS, PKI, Peter Gutmann
- Re: [TLS] TLS, PKI, and web security. Was: Eleven… Kyle Hamilton