Re: [TLS] Eleven out of every ten SSL certs aren't valid

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 01 July 2010 07:58 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 A705B3A6860 for <tls@core3.amsl.com>; Thu, 1 Jul 2010 00:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.748
X-Spam-Level:
X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.749, 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 P7RAWzXUQPLr for <tls@core3.amsl.com>; Thu, 1 Jul 2010 00:58:40 -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 956023A679F for <tls@ietf.org>; Thu, 1 Jul 2010 00:58:40 -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=1277971133; x=1309507133; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20marsh@extendedsubset.com,=20tls@ietf.org|Subject: =20Re:=20[TLS]=20Eleven=20out=20of=20every=20ten=20SSL=20 certs=20aren't=20valid|In-Reply-To:=20<4C2BB326.1010609@e xtendedsubset.com>|Message-Id:=20<E1OUEfb-0003pQ-0u@winte rmute02.cs.auckland.ac.nz>|Date:=20Thu,=2001=20Jul=202010 =2019:58:51=20+1200; bh=gMRL7wlk0rnOLPI5aOEig/VFIyMtCD1HdkyBUtv4C3k=; b=Bwnb8OK0RTTSCx0sne/6RPG2J77f/7xRo7ac2trMCw3tyd+sbYdjT2uc Q9B9nXkkhPM+Ak2tYIt5rIUvyCgfsRc6RB1cdjz4yij1ZG4L9zhF6ETDB +Oo7PbyPTecWxHksZk5DodIbYdQFTBEvR1aHTGSrqtiGyVGvjCNY/FGM8 U=;
X-IronPort-AV: E=Sophos;i="4.53,518,1272801600"; d="scan'208";a="13457095"
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; 01 Jul 2010 19:58:51 +1200
Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@cs.auckland.ac.nz>) id 1OUEfb-0003pQ-0u; Thu, 01 Jul 2010 19:58:51 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: marsh@extendedsubset.com, tls@ietf.org
In-Reply-To: <4C2BB326.1010609@extendedsubset.com>
Message-Id: <E1OUEfb-0003pQ-0u@wintermute02.cs.auckland.ac.nz>
Date: Thu, 01 Jul 2010 19:58:51 +1200
Subject: Re: [TLS] 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: Thu, 01 Jul 2010 07:58:45 -0000

Marsh Ray <marsh@extendedsubset.com> writes:
>On 06/30/2010 11:41 AM, Martin Rex wrote:
>>
>> Recoloring a part of the browser toolbar is a feature developed
>> by marketeers.  Unless it is clearly defined how things should
>> work with protocols (rfc-2818 or draft-saintandre-tls-server-id-check)
>> this approach is going to create new problems, because it completely
>> ignores programmatic clients.
>
>Not only that but it's "opt-in" validation on the part of the guy 
>running the server (be they legitimate or attacker). I kinda thought it 
>was the job of the CA to do their due diligence in authenticating the 
>applicant all along, so now charging an applicant extra for the 
>privilege of being thoroughly authenticated does not enhance their 
>credibility in my view. 

It's even worse than that.  Here's Verisign's authentication requirements for
businesses.  One is from the 1.0 CPS, which was going to Solve the Problem
fourteen years ago.  The other is from the 2008 EV-cert CPS, which is going to
Solve the Problem today.  Without going out to check, see if you can tell
which is which.  I've harmonised the style and wording a bit since it's
otherwise possible to make a pretty good guess based on the form of the text,
the current CPS has way more legalese:

  Where required, the third party confirms the business entity's name,
  address, and other registration information through comparison with third-
  party databases and through inquiry to the appropriate government entities.
  Confirmation of information of companies, banks, and their agents requires
  certain customized (and possibly localized) procedures focusing on specific
  business-related criteria (such as proper business registration). The third
  party also provides telephone numbers that are used for out-of-band
  communications with the business entity to confirm certain information (for
  example, to confirm an agent's position within the business entity or to
  confirm that the particular individual listed in the application is in fact
  the applicant). If its databases do not contain all the information
  required, the third party may undertake an investigation, if requested by
  the IA, or the certificate applicant may be required to provide additional
  information and proof.

  The third party must be a legally recognized entity whose formation included
  the filing of certain forms with the Registration Agency in its
  Jurisdiction, the issuance or approval by a Registration Agency of a
  charter, certificate, or license, and whose existence can be verified with
  that Registration Agency, and must have a verifiable physical existence and
  business presence.  If the third party represents itself under an assumed
  name, VeriSign verifies the third party's use of the assumed name.

The only difference I can see is that one CPS exhaustively itemises the
various bits and pieces that are checked whereas the other gives it in general
terms, I've left out the list itself because it'd make this a five-page
posting with not a lot more content.  If you want to see the verification
requirements for yourself, they're in section 5.1.3 (old CPS) and Appendix B1
5(c) with an almost-identical copy at 14(C) with more detail in sections that
follow (new CPS).

So all this is doing is turning the clock back 14 years, with pricing to
match.  This is why a financial cryptographer summarised EV certs as "Doing
more of what we already know doesn't work".

Peter.