[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