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

Ivan Ristic <ivan.ristic@gmail.com> Wed, 30 June 2010 06:04 UTC

Return-Path: <ivan.ristic@gmail.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 37F7C3A689C for <tls@core3.amsl.com>; Tue, 29 Jun 2010 23:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.292
X-Spam-Level:
X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599]
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 8gaARkBQGQZK for <tls@core3.amsl.com>; Tue, 29 Jun 2010 23:04:56 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A4C313A6C1F for <tls@ietf.org>; Tue, 29 Jun 2010 23:04:55 -0700 (PDT)
Received: by fxm1 with SMTP id 1so190755fxm.31 for <tls@ietf.org>; Tue, 29 Jun 2010 23:05:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QMMCo6JgRWR5nOvglpcA1QcuguYaAIkwJeTFAUq8Z7c=; b=AvVaGPeak+rjPyxkRyJYGKjJRnX2BnMt2WUavTFQ51ZG4dUjFNHd+xKTAuDKYH1aom jxSITNgNC08aj2oSAsJeIX2xG0lehlUi0Ip5WqkVnfgAYbWun+HMPYYANI9qCnb3r8YU 5/gjuODRpZl1B+3vTzDQOkmj/D+fhwnIqG5DM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IqBdlUETFeA0+WKPaJLMlNRNemoYxHTu0j2jNLYa59fEVTNxT9yW2mrmsfCHmc2bmU KhXbpBnhWBphgUgFjtXYzRxIJYkXAiBcGK/bzJTHRTShRnpjAjwhY6Tfm8h9QJRPXtag dbJLV+ktL12sCk/tmF36nJDMP8jlFKvCpu20o=
MIME-Version: 1.0
Received: by 10.239.182.207 with SMTP id r15mr499128hbg.6.1277877900224; Tue, 29 Jun 2010 23:05:00 -0700 (PDT)
Received: by 10.239.164.79 with HTTP; Tue, 29 Jun 2010 23:05:00 -0700 (PDT)
In-Reply-To: <i0e1g9$t9k$1@dough.gmane.org>
References: <E1OTVaY-0004g3-OW@wintermute02.cs.auckland.ac.nz> <20100629163354.GR11785@oracle.com> <AANLkTim6sYWlPSRUwYHP4UfkUNkfiVQ7xbj28fF6fOmz@mail.gmail.com> <20100629193416.GU11785@oracle.com> <AANLkTilF3TZn4DcjTmoKrv3Zcp441oyvWp-E9aJmH5hF@mail.gmail.com> <20100629204614.GX11785@oracle.com> <AANLkTinByiAIx1Pg4khiXLPb9KMexp2UUoZB7ikLzd6f@mail.gmail.com> <AANLkTik5HjADIdqIy4vzQrkQmP4nEwVa0xJUQ-gmkJvT@mail.gmail.com> <i0e1g9$t9k$1@dough.gmane.org>
Date: Wed, 30 Jun 2010 07:05:00 +0100
Message-ID: <AANLkTilp8KVZONKm8piOWD8JrHktS8hXVVttMKG_5Ozx@mail.gmail.com>
From: Ivan Ristic <ivan.ristic@gmail.com>
To: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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
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 06:04:57 -0000

On Wed, Jun 30, 2010 at 1:01 AM, Bruno Harbulot
<Bruno.Harbulot@manchester.ac.uk> wrote:
> Hi,
>
> On 29/06/2010 22:15, Ivan Ristic wrote:
>>
>> On Tue, Jun 29, 2010 at 10:10 PM, Tim Dierks<tim@dierks.org>  wrote:
>>>
>>> On Tue, Jun 29, 2010 at 4:46 PM, Nicolas Williams
>>> <Nicolas.Williams@oracle.com>  wrote:
>>>>
>>>> The context was just how awful it is that 97% of servers don't have
>>>> valid certs
>>>
>>> That is not what is being said. What is being said is that 97% of DNS
>>> names
>>> that point at SSL servers do not validate with those DNS names. This is,
>>> on
>>> its face, is a statement about DNS configuration, not about SSL servers.
>>> (Creating a thousand DNS names for the IP address of a single SSL server
>>> will change this stat, although the owner and operator of the SSL server
>>> need not be involved in any way.)
>
> Not even that, it's a flaw in the assumption that for each DNS name there
> will be an HTTPS server listing there. That's definitely not true.

It's the assumption accusation again. It is not an assumption. It is
test to see how many domain names have port 443/SSL/valid certificate
configured. Although you claim otherwise, there are many domain names
who respond with SSL on port 443 and have invalid certificates. Now,
we can argue what that means, and, granted, it does not mean much.
What is meaningful, is that there is an X number of domain names that
_does_ have SSL configured properly.


> However, I think there are two major problems with the study:
>  - the fact it seems to propagate the myth that a cert from a big CA is
> necessarily a "safe" cert and vice versa.

I don't like the many CAs as much as the next guy, but for the
"normal" person on the Internet today, that's the only thing to rely
on. It may be flawed, but it's less flawed than self-signed
certificates (which a normal person has a 0% chance of understanding).

> We tend to rely on the UK e-Science CA [1] for a number of machines. Some of
> my machines with UK e-Science certs score like this:
>  - Certificate: 0 (unknown CA)
>  - Protocol Support: 85
>  - Key Exchange: 90
>  - Cipher Suites: 90
>
> That would get a "green A" if the CA was recognised. Unfortunately, it's not
> known by the tool, so it's disqualified. That's a bit harsh, isn't it?

It may be, but I get a certificate warning when I go to
https://www.ngs.ac.uk/. It's the same thing.

The tool is designed from a perspective of an average Firefox user.
It's an SSL client implementation, just like any other browser/client.

I'd love to support multiple trust bases (as well as custom trust
stores), but the maintenance of multiple trust stores is too much work
for me to handle right now.

-- 
Ivan Ristic
ModSecurity Handbook [http://www.modsecurityhandbook.com]
SSL Labs [https://www.ssllabs.com/ssldb/]