It's 10pm, do you know where your SSL certificates are?

Posted: Tue, 7 July 2015 | permalink | 4 Comments

The Internet is going encrypted. Revelations of mass-surveillance of Internet traffic has given the Internet community the motivation to roll out encrypted services – the biggest of which is undoubtedly HTTP.

The weak point, though, is SSL Certification Authorities. These are “trusted third parties” who are supposed to validate that a person requesting a certificate for a domain is authorised to have a certificate for that domain. It is no secret that these companies have failed to do the job entrusted to them, again, and again, and again. Oh, and another one.

However, at this point, doing away with CAs and finding some other mechanism isn’t feasible. There is no clear alternative, and the inertia in the current system is overwhelming, to the point where it would take a decade or more to migrate away from the CA-backed SSL certificate ecosystem, even if there was something that was widely acknowledged to be superior in every possible way.

This is where Certificate Transparency comes in. This protocol, which works as part of the existing CA ecosystem, requires CAs to publish every certificate they issue, in order for the certificate to be considered “valid” by browsers and other user agents. While it doesn’t guarantee to prevent misissuance, it does mean that a CA can’t cover up or try to minimise the impact of a breach or other screwup – their actions are fully public, for everyone to see.

Much of Certificate Transparency’s power, however, is diminished if nobody is looking at the certificates which are being published. That is why I have launched sslaware.com, a site for searching the database of logged certificates. At present, it is rather minimalist, however I intend on adding more features, such as real-time notifications (if a new cert for your domain or organisation is logged, you’ll get an e-mail about it), and more advanced searching capabilities.

If you care about the security of your website, you should check out SSL Aware and see what certificates have been issued for your site. You may be unpleasantly surprised.


4 Comments

From: Daniele
2015-07-07 08:07

Hello.

You say that there is no alternative to the current centralized CA based SSL model. Would you like to comment on why you think that DNSSEC+DANE are not a possible and much better alternative?

Thanks. Cheers, Daniele

From: Matt Palmer
2015-07-07 09:57

Hi Daniele,

The full rationale for why DNSSEC+DANE is (unfortunately) never going to go anywhere is rather too large to put in a comment, so I’ll write up a separate post on this subject tomorrow. The short version, though, is that DANE fails the “widely acknowledged to be superior” test – no major browser currently implements it, and (at least) the Chrome developers have some fairly sensible arguments why DANE isn’t workable at Internet scale, which I’ll cover in my full post tomorrow.

From: al
2015-07-13 23:25

i fail to see how this certificate transparency fixes anything at all.

The problem as i see it is not that a well known ca creates a fake certificate, but rather than any of the hundreds of ca can issue a certificate for google.com (this is not longer that easy thanks to HPKP and hopefully letsencrypt.com will do the rest)

I also fail how are they going to log every cert they issue… i skimmed the log system… but thats just software… and a ca its only a private key that can be copied over and used on other machine… in essence this seems to rely on the ca good will… but thats how it works right now…

From: Matt Palmer
2015-07-14 02:05

Hi Al,

The piece that you may have missed is that, in a Certificate Transparency world, in order for a certificate to be considered “valid”, it must come with proof that the cert has been logged. This comes in the form of a signature generated by a CT log which the browser recognises. This signature can be delivered in a number of different ways:

  • embedded in the certificate (at the time certificate is issued, the CA logs the certificate, and takes the resulting signature and puts it inside the cert, as an X509v3 extension);
  • delivered in the TLS handshake, as a TLS extension; or
  • delivered in the OCSP response (which should be stapled, for maximum reliability).

This means that logging the certificate isn’t optional – in a fully-CT-enabled world, an unlogged certificate from an otherwise-trusted CA would look exactly the same as a certificate issued by an untrusted CA.

Post a comment

All comments are held for moderation; markdown formatting accepted.

This is a honeypot form. Do not use this form unless you want to get your IP address blacklisted. Use the second form below for comments.
Name: (required)
E-mail: (required, not published)
Website: (optional)
Name: (required)
E-mail: (required, not published)
Website: (optional)