Is HTTPS security broken


For some years HTTPS web security has been considered pretty dependable. If I’m connected to a website, the right URL is showing in my browser and I have a padlock symbol then I’m probably talking to the site that I think I am (extra points for actually checking the security certificate details to make sure the site owner is who I think it is).

The security of the whole thing depends on the server credentials issued by trusted Certification Authorities. Once a rogue or negligent CA is included in the list of CAs trusted by my browser then I have no security at all as certificates can be manufactured which fool me into thinking that I have a secure session when in fact I’m talking to a bad guy in the middle of my connection and giving them all of my data.

Compromise of CAs trusted by mainstream browsers has happened at least 4 times that we know of and the practice of deploying corporate HTTPS proxies which work with locally installed root-CAs to fake remote sites credentials and allow internal IT departments to snoop employees HTTPS traffic seems to have become a legitimate practice.

Being gifted trusted CA status by the mainstream browser vendors is almost literally a licence to print money. It allows the organisation to charge a fee for issuing delegated certificates which amount to nothing more than a string of binary digits. It has to be the highest margin industry on the planet, essentially selling a “blessed” version of a free resource. All that is required for the whole system to stay secure is that the CA demonstrably keeps its signing mechanisms secure and issues only specific resource certificates to organisations that are able to prove that they own the subject resource. Surely that isn’t too much to ask.

In the early days of this industry it all worked pretty well, a small number of players that fully understood the technology signed server certificates directly with their root certificate after performing proper real-world checks to ensure the person that they were handing the certificate to really did exist and own the resource. For good technical reasons many CAs introduced an extra level of delegation so that the certificate which actually signed the server credentials was an intermediate which carried the authority of the root CA. This ability to delegate a signing authority has always been a designed in part of the mechanism and it improves the security of the whole signing process provided both stay firmly in the control of the CA.

Since then there has been an explosion of CAs and an inevitable race to the bottom to offer the cheapest and most accessible way of buying a “padlock” for our websites. This site has an SSL certificate which could give you enhanced confidence that it is my words you are reading now. Your confidence is pretty unjustified as, whilst it is a full legitimate SSL certificate, it cost me just under £10 late on Friday night in a transaction that took a couple of minutes all told from start to finish. I paid for it by paypal from an e-mail address that wasn’t even associated with the domain, not even a real credit card transaction. The only verification that was needed was the ability to read one e-mail in my choice of mailbox associated with the domain for long enough to grab a confirm link from it. That’s about the same level of verification than you would need to say sign up to an e-mail newsletter.

It isn’t exactly news that I can get a basic SSL certificate for my no-name website for pennies without having to show who I am, and to be fair there are much more secure EV certificates at the other end of the market that provide much higher levels of checking and therefore confidence, but does the average person in the street know the difference when deciding to trust a site?

Of far more concern are the instances of CAs manufacturing intermediate signing certificates and then losing control of them. These intermediate signing certificates carry the full authority of the CA and they can be used to generate certificates which allow anyone to pretend to be, or snoop traffic for, any Internet site they wish. In a recently disclosed incident a CA called TurkTrust, who were trusted by all of the major browser vendors managed to give fully capable intermediate certificates away to two end users, apparently by innocent accident. One of the recipients later installed it on a traffic interception device and started using it to intercept user sessions to

In another similar incident a CA sold one of their intermediate signing certificates to a company for the purposes of intercepting secure web sessions originating from within their corporate network. To their credit, once this was publicised they did a U-turn, decided to revoke it and stated that they would never do this again. On balance of probabilities it is likely that more of these intermediate signing certificates are lurking out there on the Internet. If a CA could be persuaded to risk their credibility and therefore entire business by agreeing to generate one for a corporate in exchange for money, I wonder what happens when a government agency comes knocking.

If that doesn’t sound like too much of a real world problem unless you are a gangster or terrorist, consider that the state involved may not be be a liberal democracy that respects due process of law or free speech. One of the notable recent CA failures was DigiNotar a Dutch CA who’s systems were compromised to issue certificates which were then used in Iran by persons unknown to grab secure traffic intended for Gmail, Yahoo!, Facebook and Tor (an anonymous web browsing service) among others. It’s not hard to see why a repressive government may be prepared to go to quite some length to get an “Internet master key” that allows them to see straight through any private traffic from citizens within their country and it isn’t clear to me that our current sprawling browser CA landscape is particularly resilient against this or other similar threat models.

So what do we do about this: do we need fewer trusted CAs in our browsers by default — if so which ones and how do we choose?

Should trusted CAs be forced to disclose all intermediate signing certificates that they generate and be explicitly banned from allowing unconstrained signing certs to leave their own control?

Should we have laws to set expectations about what CAs should do? Establishing national laws to fix Internet problems doesn’t have a great track record for pretty good reasons, but it does seem reasonable to have society set legal expectations that manufacturing, handling or applying fake digital credentials are unacceptable behaviours. Forging bank notes or written signatures are very serious criminal matters in most cultures, unlike undermining the entire global web security model which seems to have no hard sanctions at all. Sure it won’t prevent criminals from doing their thing, but it would make the CEO of a CA subject to criminal sanctions if their organisation steps over a line in passively or actively enabling such activities. All that browser vendors then need to do is ensure that any CAs they bless establish their operating bases in a country where these laws exist.

Perhaps we should ditch the whole concept of browser vendors blessing a vast commercial CA swamp and try to find a workable model where users get to choose which certificate issuers they want to trust. This is a bit like the PGP style web of trust where users personally verify any party that they trust and then rely on their verification of others. There is a major technical problem with this approach because, unlike PGP, X509 only supports a single certificate per public key so the trust inheritance is a strict tree rather than a web, as a server administrator I can only present one chain of certificates and if the trusted party my visitor has chosen isn’t in my CA chain then they aren’t going to get the green padlock.

The only place we can currently have a one to many trust relationship is at the root CA list level so maybe the fix is to have independent lists of root CAs at this level assembled by folks other than the browser vendors. At install time, present users with a meta-list of possible CA roots and have them choose one. The only CA pinning needed in the browser would then be to the repositories of the meta-CAs. Users could decide if they wanted to use a list curated by for example their favourite security vendor, government or perhaps the EFF. That way if I want a root CA list which contains only those who guarantee that they don’t sell intermediate signing CAs to dodgy foreign government telcos or issue or $10 no questions asked “domain validation” certs then I choose a list curated with those criteria. I can see that some browser vendors would want to keep their direct relationships with the CAs, but others may just jump at the chance to get out of the business of vetting Honest Achmed’s business plan