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

Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> Wed, 30 June 2010 07:35 UTC

Return-Path: <ietf-ietf-tls@m.gmane.org>
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 807F93A67BD for <tls@core3.amsl.com>; Wed, 30 Jun 2010 00:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 bJtaznluyWmb for <tls@core3.amsl.com>; Wed, 30 Jun 2010 00:35:11 -0700 (PDT)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id 75FF93A68CB for <tls@ietf.org>; Wed, 30 Jun 2010 00:35:05 -0700 (PDT)
Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from <ietf-ietf-tls@m.gmane.org>) id 1OTrpC-0004xM-M6 for tls@ietf.org; Wed, 30 Jun 2010 09:35:14 +0200
Received: from rain.gmane.org ([80.91.229.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Wed, 30 Jun 2010 09:35:14 +0200
Received: from Bruno.Harbulot by rain.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Wed, 30 Jun 2010 09:35:14 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
Date: Wed, 30 Jun 2010 08:35:05 +0100
Lines: 98
Message-ID: <i0es3a$std$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> <AANLkTilp8KVZONKm8piOWD8JrHktS8hXVVttMKG_5Ozx@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: rain.gmane.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
In-Reply-To: <AANLkTilp8KVZONKm8piOWD8JrHktS8hXVVttMKG_5Ozx@mail.gmail.com>
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 07:35:12 -0000

Hi,

On 30/06/2010 07:05, Ivan Ristic wrote:

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

Sure, but that's exactly the problem, the assumption that they should
have a valid cert there. It's more than that, it the assumption that
there would be a web server at all behind a domain name (admittedly,
that's very likely to be the case but the internet and the web are not
quite the same thing.)

You seem to have missed a fundamental point of the architecture of the
WWW: the fact that you're meant to navigate it through linking, not by 
guessing from a domain name.

Of course, guessing the website from the domain name is likely to give 
some good results. There are a few assumptions on the way there.


You're making the assumption that for "example.com" there will be a
"http://www.example.com/". It's a good assumption, but it's still an
assumption. Who said there should be an HTTP server listing? Next
assumption is that there will be a 'www' prefix.

The PDF <https://www.ssllabs.com/projects/rating-guide/index.html> says:
> Make sure the certificate is valid for all the domain names that will
> be required. For example, make sure the certificate works for
> www.example.com as well as example.com (without the www part).

Why should there be a server at both 'http://www.example.com/' and 
'http://example.com/'? (Some browsers auto complete the www prefix, but 
that's no more than common practice, it's by no means any sort of 
requirement.)

You seem to merge the concept of domain name and host name, they're
not quite the same thing, especially with 'www'.

What your studies shows is that the next step up in guessing what to
contact based on a domain name (from http:// to https://) is less likely 
to be a correct guess. Fair enough, I suppose, but these are still 
assumptions (with respect to host name and PKI).


The main problem with this study is that it makes assumptions about the 
architecture of the WWW that are not true. There is a reason why links 
use URIs with a scheme and not just a domain name.


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

Sure, it's not an ideal situation, but it has the advantage that it 
offers a reasonable trade-off between the technical aspect and the 
user-interface aspect of security. (I'm still not fully convinced of the 
benefits of EV, though.)


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

It doesn't work for me either (probably some other reason than the 
certificate), but that's the point I'm saying above: I never said there 
should be something at <https://www.ngs.ac.uk/> and no one ever said 
that to me either.



Best wishes,

Bruno.