What's wrong with HTTPS: Part 3 - Certificate governance

In the previous part we established that any certificate authority can issue a certificate to any website, even if the website admin doesn't want them to do that. This post is about technical measures attempting to monitor certificate authorities' actions.

Details that need to be addressed somehow

A certificate lifecycle is very simple. One is issued by a CA, it is used by a server and eventually it expires. When things go sideways, the server administrator may want to revoke an otherwise valid and good certificate, so there needs to be a mechanism to handle a single special case. So, two actions: issuance and revocation. Everything else is handled by itself.

To monitor certificate issuance and revocation, following requirements apply:

• Monitor when somebody issues a certificate for your website
  • Preferably everybody in the entire Internet needs to know about this instantly. You decide if the issuance is good or bad thing.
• Man-in-the-middle using a fake certificate
  • When a subset of users is being targeted, clients need to know that the certificate being offered doesn't belong to the server the certificate supposedly is for.
• No trusted parties
  • This is something we learned from X-Files (the TV-show), trust no one! Any possible parties needed in verification must be assumed to be offering false information, or alternatively it needs to be digitally tamper-proof.
• Instant deployment of a new certificate
  • When you setup a server and a certificate to it, how do you notify everybody about that? Preferably no notification is needed.
• No need to modify servers
  • How is the actual server setup done. What parts you need to add there. Preferably none.
• No additional requests during connection
  • When a client requests data from your server, which additional requests to another parties are needed? Preferably none. Remember, that this type of additional request need to succeed in a split-second to make the decision wheter to open a connection to a requested server or not.

(This list is actually "borrowed" from certificate transparency tech comparison. Its just so comprehensive, so I had no other option than to use it.)

Certificate revoke list, aka. CRL

This is what we have since dawn of SSL. The idea is to go request the issuing CA and see if an already issued valid certificate is revoked. This information is published in a revocation list. The obvious problem is that revocation information doesn't happen instantly, and actually most browsers don't ever check a CRL.

To distribute the CRL-information, an issued certificate is supposed to have an URL to CRL (typically they do) and a client is supposed to be downloading that data periodically (typically they don't). In reality that doesn't work, as nobody wants to spend their precious time and bandwidth for downloading a ever-growing list of bad certs. To address that, there is a modern approach, Online Certificate Status Protocol or OCSP. It is supposed to be much faster operation with minimal bandwidth usage.

Neither of these really work well because of the need for an additional request. Also OCSP has a major fault, that a reply can be stored and "played back" on a query, so the reliability is more than questionable.

Certificate Transparency

This is the newest one and it has a good chance of becoming the commonly accepted method for tracking certificate issuers' actions. There is an RFC 6962 defining Certificate Transparency and the source code is distributed as open-source allowing anybody to see how it works and do their own audit on it. Originally the project is initiated by Google, but number of CAs already accepted the technology including Symantec, Digicert. and Globalsign. One reason for wide adoption is, that Google (the author of Chrome browser), made an ultimatum, that the seriously expensive Extended Validation certificates need to have CT signature in them for Chrome to accept them as valid.

Internally CT works with a Merkle hash tree, something that BitCoin uses internally. So, it is safe to say, that this technolocy is a blockchain. Blockchain as a tech is quite new, but robust and reliable. The good thing about Certificate Transparency is, that this tech supports all requirements from above list. All a browser needs to do is periodically load the CT logs and during a connection, read the CT-signature from server's certificate, and based on that a browser can instantly verify or decline the server's certificate.

As mentioned, Certificate Transparency needs to be supported by your browser. Being a Google project, of course Chrome does support CT since version 35. Mozilla Firefox has announced support for CT, but at the time of writing there is no implementation yet. Microsoft doesn't support CT and they announced that that they're doing something of their own for IE11, naturally their new Edge browser doesn't support CT either. So that pretty much lands Chrome being the only browser really supporting this. The good thing is, that there exists many server-to-server monitors, for example Certificate Transparency Monitor.

Not accounting for poor browser support, another weakness CT has is that every certification authority has to include CT-signature in their issued certificates and publish their CT logs to general public.

DANE

DNS-based Authentication of Named Entities, or DANE is the first serious attempt to enforce certificate's ownership. The tech is described in RFC 6698 and multiple accompanying RFCs to clarify details of it's implementation. However, DANE hasn't received much public acceptance.

This is how Wikipedia defines DANE: "DANE enables the administrator of a domain name to certify the keys used in that domain's TLS clients or servers by storing them in the Domain Name System (DNS). DANE needs the DNS records to be signed with DNSSEC for its security model to work."

As the above definition says, for DANE to work, a prerequisite is functioning DNSSEC. Nobody has that! Some stats at http://rick.eng.br/dnssecstat/ show that the situation is horrible. So, no DNSSEC, no DANE. Also DANE fails on two other things: additional requests are needed to DNS during connection and you need to trust the DNS-server response. DNS data can be forged or poisoned, so there's that.

Pinning

Certificate pinning, or HTTP Public Key Pinning is an extension header of a HTTP-response. This is yet another Google-project, but its not widely adopoted. The idea for the web server to send public key information on every response, then the web browser is supposed to locally store the information for specified time. Then any subsequent responses from that same server are supposed to have the same information in them what was cached before. Weakness is that, the initial request needs to go to the real server. If your traffic was "man-in-the-middled" already at that point, you won't get any warnings.

Pinning is supported in Chrome and Firefox, but as Microsoft nor Apple support this, it is missing from IE, Edge and Safari. There is a funny mistake in Microsoft Edge's feature list as it states Firefox not supporting pinning, but Firefox was one of the early browsers supporting this feature.

Weaknesses here are, that it requires changes both on server and client sides. Also, when the certificate is legitimately changed, there really isn't a sensible mechanism to inform about that.

Collecting every web server certificate, aka that thing Google is doing

As you may remember from part 2 of this series, most of the rogue certificates issued are for Google services. So, they're fighting this by collecting all the certificates they see. They have a massive army of bots crawling web servers all the time. Google is also publishing their findings in a Certificate Transparency log for any interested parties to see. As mentioned before, there are publicly available non-Google services monitoring the CT-logs for abnormal changes.

This is very simple idea, if you see your certificate listed there, the certificate was issued by your request or somebody else's. It should be rather simple task to determine which one was it.

Anybody can use the human interface at Google Transparency Report site.

The future?

None of these technologies is really either useful, or widely adopted by major vendors. Fact remains: due to number of past incidents Certificate Authorities need to be monitored, supervised and publicly scrutineered. The best thing to attempt is to add some transparency to their actions. Which technology that would be is yet to be seend. What worries me is Apple's and Microsoft's total ignorance for this matter. I guess they'll need to be targeted first to wake up from their deep sleep.

This is the last part of my HTTPS-series. First part was about basics of trusted certificates and second part part was about misappropriation of trust.