Re: [TLS] TLS, PKI, and web security. Was: Eleven out of every ten SSL certs aren't valid

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 03 July 2010 07:09 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 44B133A67FE for <tls@core3.amsl.com>; Sat, 3 Jul 2010 00:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.871
X-Spam-Level:
X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-0.872, 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 29mt0+OVjN7N for <tls@core3.amsl.com>; Sat, 3 Jul 2010 00:09:37 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 72A2C3A67FB for <tls@ietf.org>; Sat, 3 Jul 2010 00:09:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1278140990; x=1309676990; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20marsh@extendedsubset.com,=20pgut001@cs.auckland.ac .nz|Subject:=20Re:=20TLS,=20PKI,=20and=20web=20security. =20Was:=20[TLS]=20Eleven=20out=20of=20every=20ten=20SSL =20certs=20aren't=20valid|Cc:=20asteingruebl@paypal.com, =20tls@ietf.org|In-Reply-To:=20<4C2DA79B.9040500@extended subset.com>|Message-Id:=20<E1OUwrF-0002OS-AG@wintermute02 .cs.auckland.ac.nz>|Date:=20Sat,=2003=20Jul=202010=2019:0 9:49=20+1200; bh=j0IuggYTojZQn7i7dxdUrqT3AyitZfgVKBmp8JsHU34=; b=hm+V1EcylgjyVC7MpmQRxtoflm61A5KT7bR/N1Ht7foC/FBp6vKtgb62 MKKOHRpzmlMmS08K48nBwdNsd/wfjca1ieYD6gSlsgdgPsncNr9VwAxbu XN29ruSCP3d4zYRjVyMeyiz6Ad/rGbDb5aptJFrKRmsMmtIcKlXlPGO71 I=;
X-IronPort-AV: E=Sophos;i="4.53,530,1272801600"; d="scan'208";a="13678954"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing
Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Jul 2010 19:09:49 +1200
Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@cs.auckland.ac.nz>) id 1OUwrF-0002OS-AG; Sat, 03 Jul 2010 19:09:49 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: marsh@extendedsubset.com, pgut001@cs.auckland.ac.nz
In-Reply-To: <4C2DA79B.9040500@extendedsubset.com>
Message-Id: <E1OUwrF-0002OS-AG@wintermute02.cs.auckland.ac.nz>
Date: Sat, 03 Jul 2010 19:09:49 +1200
Cc: tls@ietf.org
Subject: Re: [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: Sat, 03 Jul 2010 07:09:39 -0000

[Just a general note, if people think this is off-topic and want it moved to
 private mail I'd be happy to do that, but I think it's an interesting
 discussion, TLS is more than just getting the bits on the wire right, it's
 also a matter of applying it effectively]

Marsh Ray <marsh@extendedsubset.com> writes:

>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.

If browsers implemented credential security properly (client-side password
deversification and failsafe mutual auth) then the only one on that list
that'd still be a threat is man-in-the-browser attacks, and for that one, once
your machine is 0wned it's pretty much game over anyway.  So there are things
that can be fixed, they're just not getting fixed.

>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.

Uhh, going back to the list of studies again, there's been study after study
after study showing they are ineffective - they have next to no effect on user
behaviour.  I'll list just one of them:

  "You've Been Warned: An Empirical Study of the Effectiveness of Web Browser
  Phishing Warnings", Serge Egelman, Lorrie Cranor and Jason Hong, Proceedings
  of the 2008 Conference on Human Factors in Computing Systems (CHI.08), April
  2008, p.1065.

because the title sprung to mind when you mentioned "browser warnings".  These
things don't work.

>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.

My interest is in keeping real-world users secure.  If I'm providing security
tools that don't do that then I'm not doing my job properly.  It's not the
user's job to learn whatever geeky stuff I think they need to know, it's my
job to give them something that keeps them secure (or at least as secure as
possible under the circumstances, I can't do much about an 0wned PC).  So I
think it is very valid to discuss it in terms of lowest-common-denominator
users, because that's who'll be using our tools.

>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.

Uhh, but what does that have to do with protecting users going to bank and
online shopping web sites?

(Two points in response to this: (1) if you control the environment then you
can push out pretty much anything you want as your security system, including
nothing at all (geographic entitlement, to authenticate yourself you have to
enter the room where the equipment is and plug in an ethernet cable), so this
isn't really a major feat, and (2) compared to the Internet at large there are
close to zero attacks on these sorts of systems (and in the odd exceptions
when SCADA-type stuff has been attacked in the past it's been found to be
swiss cheese), so "successfully using TLS" really means "we got data from A to
B", not "it's been proven resistant to a concerted attack").

>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.

Uh... I thought it was to protect Joe Sixpack from having his credit card
stolen?  Professional sysadmins are the last person you want to worry about
optimising for, any sysadmin worth his salt will be able to secure their data
given no more than chewing gumm and rubber bands.  It's the 1.7-billion or so
global population of users who aren't professional sysadmins that I'm
interested in helping, not a handful of sysadmins somewhere.

>* 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.

Umm... I better not reply to a statement like this, because the response would
be... inflammatory.

>* 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.

Steffen, you've won your prize :-).

(For people who don't get the ref, it's:

 "Now comes the part where somebody replies that this is all solved by client
 certificates and the discussion is closed 'til next time...)"

Peter.