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

[Bruno Harbulot <[e-mail]>]

Hi,

On 29/06/2010 22:15, Ivan Ristic wrote:
> On Tue, Jun 29, 2010 at 10:10 PM, Tim Dierks<[e-mail]>  wrote:
>> On Tue, Jun 29, 2010 at 4:46 PM, Nicolas Williams
>> <[e-mail]>  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.



>> To learn anything interesting about SSL servers at all, more work must be
>> done.
>
> Yes, of course. I am attaching some of the metrics I will be
> collecting from the 720K domains that have potentially valid
> certificates. That's the meat of my survey.
>
> It's too late to change the metrics now (I've started with the
> collection), but the plan is to continue with the survey indefinitely.

I suppose it depends on what you've collected, in particular whether 
you've kept some of the raw data before giving a "red F" with score 0 to 
a certificate.



I think https://www.ssllabs.com/ssldb/ is a fairly neat tool. I've 
scanned a couple of machines I'm hosting, and it diagnosed a weak cipher 
suite on one of them, which I was able to correct. Thanks for that!


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.
   - the fact that it assumes that a domain name will have one IP 
address on its own or that servers all support SNI.


1. Non-major CAs -> score 0, regardless of the other indicators.

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?

To give you a bit of background, to get a certificate (server or client) 
with this CA, I've had to turn up in person to see one of the CA 
representatives and show an official photo ID. How many CAs that are 
trusted out of the box in major browsers require that?
... And for all that trouble, I only get a blue bar in my browser (when 
I've imported the CA cert, of course). Surely, that would be worth a 
green bar!


I would expect a bit more care in the wording (especially with quite a 
graphic colour ranking) when it comes to these issues. The accompanying 
document explains a bit the problem, but probably not well enough. 
Non-experts, including journalists after some sensational piece of news 
would quite easily focus on the "big red F" on that webpage, not 
necessarily understanding that it's in fact meaningless out of context.

Admittedly, I have much less experience than many other people on this 
list, but I still hope TLS experts understand that Big CAs and EV 
certificates are not the perfect solution for trust management. (There 
probably isn't one anyway.)



2. Host names.

There are a number of shared web hosting providers that have a large 
number of host names hosted on the same IP address. (Typically, with 
VirtualHosts on Apache Httpd). Sometimes, these servers will also have 
something listening on port 443 for a specific host name (perhaps a 
common admin interface or something like that, maybe not even intended 
to be used by the admin in which case a self-signed certificate would be 
just fine.)
I suspect that many domains never really intended to host content over 
HTTPS there.
Drawing the conclusion that there ought to be an HTTPS server with a 
certificate with the host name that the tool is after (as opposed to the 
host name the user would have used) is quite a short-cut.

This could be solved with SNI, but considering that SNI was only 
introduced in Apache Httpd (mainstream) in May 2009 [2], it's not really 
surprising that it's not widely deployed in production systems yet.


The point is that, before testing whether a certificate is valid, you 
should check whether there is a validity test to be made, in particular 
whether someone said there would be an HTTPS server there.
 From what I understand, the collection of names was more or less made 
from the whois registry. Have you found an https URI for each an 
everyone of them? Did you add the "www" prefix by default? If no one has 
claimed there would be a "secure website" at that domain, why would you 
test that non-existent claim?



The tool is a good idea, however, the conclusions are flawed (and the 
esecurityplanet.com article focusses on the bits that are wrong.)



Best wishes,

Bruno.


[1] http://www.ngs.ac.uk/cacerts
[2] http://svn.apache.org/viewvc?revision=776281&view=revision