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

Martin Rex <mrex@sap.com> Wed, 30 June 2010 23:03 UTC

Return-Path: <mrex@sap.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 2F0AA3A693E for <tls@core3.amsl.com>; Wed, 30 Jun 2010 16:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.843
X-Spam-Level:
X-Spam-Status: No, score=-6.843 tagged_above=-999 required=5 tests=[AWL=-1.186, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_OEM_SOFT_IS=1]
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 9J4ZEj-IK3ad for <tls@core3.amsl.com>; Wed, 30 Jun 2010 16:03:36 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id C3F183A692E for <tls@ietf.org>; Wed, 30 Jun 2010 16:03:35 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5UN3jlG026801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jul 2010 01:03:45 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006302303.o5UN3hiO010982@fs4113.wdf.sap.corp>
To: aerowolf@gmail.com
Date: Thu, 1 Jul 2010 01:03:43 +2600 (MEST)
In-Reply-To: <gb2nlzqvw3n5jaet0dJYNxe982v3j_gmsm@mail.gmail.com> from "aerowolf@gmail.com" at Jun 30, 10 02:03:40 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
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
Reply-To: mrex@sap.com
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: Wed, 30 Jun 2010 23:03:37 -0000

What I entirely forgot to mention:

Thank you Ivan for setting up this SSL Test as a publicly accessible service!
It is a really neat tool and collects a lot of quite useful information.

(Unsurprisingly, I don't agree with _some_ of the scoring/conclusions).

aerowolf@gmail.com wrote:
> 
> On Tue, Jun 29, 2010 at 7:38 AM, Martin Rex <mrex@sap.com> wrote:
> >
> > It is simply impossible to come up with meaningful numbers if
> > you starting point is DNS-records and accessible hosts.
> 
> Out of curiosity, where would you suggest that the starting
> point for meaningful numbers be?


The conclusion that only 3.17% of the SSL-Servers out there show
valid SSL certificates does _not_ match reality, so the collected
data clearly does not provide a ground for some of the conclusions
that have been drawn.

Drawing conclusions about the SSL-Servers that present an "acceptable"
certificate is less of a problem, but making any assessments about
hosts where the Servers cert does not match without any proof that
this is not what the _owner_ of that host intended amounts to
wild guessing.  Making assumptions what the owner might have or
should have intended is just wrong.  In many cases, if you looked at
the contents of the served pages, you might realize that their
either is no Web-Server (configured) behind the requested hostname
at all, or it might be a different hostname than what you expected.


DNS is not a database of Web-Servers, much less a database of
TLS-enabled Web-Servers.  While there is a certain likelyhood
that a DNS entry called "www.f.q.d.n" points to a (HTTP) Web-Server,
the assumption that this Web Server could be reached via HTTPS on
port 443 is obviously flawed (as indicated by the 3.17% success rate).


SSL server certificates that Web browsers will trust out-of-the-box
is first of all a CA business model, since SSL server certificates
cost a significant and yearly recurring fee -- a fee that often
exceeds the yearly fee of the web-hosting plus domain name
for some of the hosters.  Virtual Webhosting is one of the reasons
why you can get it fairly cheap.   In face of the depletion of
IPv4 address space, the amount of virtual (http) hosting is
probably increasing every day. 


It has been previously mentioned by others: the importance of the
SSL Server cert being issued by one of the CAs that is distributed
as pre-trusted with Web-Brosers is largely overestimated.  Every day
I stumble over new reasons just how broken that trust anchor
distribution scheme is.

One of the CAs has started moving to a 2048 RSA-cert (still sha1 though)
last year, and the X.509v3 self-signed cert that is distributed with
browsers contains several X.509v3 extensions such as extendedKeyUsage
and subject/authorityKeyIdentifiers -- but it LACKS the basic Constraints
(allowed to act as a CA marked criticial) -- which is why our OEM
PKI software rejects certificate chains with that cert at the end.  
I mean this is an obvious clear defect, but Browsers such as MSIE,
Firefox and Opera ship more than one defective cert as pre-trusted.


-Martin