Iranian hackers obtain fraudulent HTTPS certificates: How close to a Web security meltdown did we get?
On March 15th, an HTTPS/TLS Certificate Authority (CA) was tricked into issuing fraudulent certificates that posed a dire risk to Internet security. Based on currently available information, the incident got close to — but was not quite — an Internet-wide security meltdown. As this post will explain, these events show why we urgently need to start reinforcing the system that is currently used to authenticate and identify secure websites and email systems.
There is a post up on the Tor Project's blog by Jacob Appelbaum, analyzing the revocation of a number of HTTPS certificates last week. Patches to the major web browsers blacklisted a number of TLS certificates that were issued after hackers broke into a Certificate Authority. Appelbaum and others were able to cross-reference the blacklisted certificates' serial numbers against a comprehensive collection of Certificate Revocation Lists (these CRL URLs were obtained by querying EFF's SSL Observatory databases) to learn which CA had been affected.
The answer was the UserTrust "UTN-USERFirst-Hardware" certificate owned by Comodo, one of the largest CAs on the web. Comodo has now published a statement about the improperly issued certs, which were for extremely high-value domains including google.com, login.yahoo.com and addons.mozilla.org (this last domain could be used to trojan any system that was installing a new Firefox extension, though updates to previously installed extensions have a second layer of protection from XPI signatures). One cert was for "global trustee" — not a domain name. That was probably a malicious CA certificate that could be used to flawlessly impersonate any domain on the Web.
Comodo also said that the attack came primarily from Iranian IP addresses, and that one of the fraudulent login.yahoo.com certs was briefly deployed on a webserver in Iran.1
What should we do about these attacks?
Discussing problems with the revocation mechanisms that should (but don't) protect users who don't instantly get browser updates, Appelbaum makes the following assertion:
If the CA cannot provide even a basic level of revocation, it's clearly irresponsible to ship that CA root in a browser. Browsers should give insecure CA keys an Internet Death Sentence rather than expose the users of the browsers to known problems.
Before discussing whether or not such a dramatic conclusion is at all warranted, it is worth considering what the consequences of blacklisting Comodo's UserTrust CA certificate would have been. We used the SSL Observatory datasets to determine what had been signed by that CA certificate. The answer was that, as of August 2010, 85,440 public HTTPS certificates were signed directly by UTN-USERFirst-Hardware. Indirectly, the certificate had delegated authority to a further 50 Certificate Authorities, collectively responsible for another 120,000 domains. In the event of a revocation, at least 85,000 websites would have to scramble to obtain new SSL certificates.
The situation of the 120,000 other domains is more complicated — some of these are cross-certified by other root CAs or might be able do obtain such cross-certifications. In most — but not all — cases, these domains could continue to function without updating their webserver configurations or obtaining new certs.
The short answer, however, is that the Comodo's USERFirst-Hardware certificate is too big to fail. If the private key for such a CA were hacked, by the Iranians or by anybody else, browsers would face a horrible choice: either blacklisting the CA quickly, causing outages at tens or hundreds of thousands of secure websites and email servers; or leave all of the world's HTTPS, POP and IMAP deployments vulnerable to the hackers for an extended period of time.
Fortunately, Comodo has said that the master CA private keys in its Hardware Security Modules (HSMs) were not compromised, so we did not experience that kind of Internet-wide catastrophic security failure last week. But it's time for us to start thinking about what can be done to mitigate that risk.
Cross-checking the work of CAs
Most Certificate Authorities do good work. Some make mistakes occasionally,2 but that is normal in computer security. The real problem is a structural one: there are 1,500 CA certificates controlled by around 650 organizations,3 and every time you connect to an HTTPS webserver, or exchange email (POP/IMAP/SMTP) encrypted by TLS, you implicitly trust all of those certificate authorities!
What we need is a robust way to cross-check the good work that CAs currently do, to provide defense in depth and ensure (1) that a private key-compromise failure at a major CA does not lead to an Internet-wide cryptography meltdown and (2) that our software does not need to trust all of the CAs, for everything, all of the time.
For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.
We don't think this is an unsolvable problem. There are ways to reinforce our existing cryptographic infrastructure. And building and deploying them may not be that hard. Look for a blog post from us shortly about how we should go about doing that.
- 1. This is strong circumstantial evidence that the attack was perpetrated by Iranians, though it also possible that the perpetrators used compromised systems in Iran in order to frame Iran.
- 2. A few previous examples.
- 3. These numbers are from the SSL Observatory. Before we performed those scans, we are unsure that anybody knew how many CAs were trusted by our browsers and operating systems, because CAs regularly delegate authority to subordinate CAs without announcing this publicly
Recent DeepLinks Posts
Aug 24, 2016
Aug 23, 2016
Aug 22, 2016
Aug 22, 2016
Aug 19, 2016
- Abortion Reporting
- Analog Hole
- Anti-Counterfeiting Trade Agreement
- Artificial Intelligence & Machine Learning
- Bloggers' Rights
- Border Searches
- Broadcast Flag
- Broadcasting Treaty
- Cell Tracking
- Coders' Rights Project
- Computer Fraud And Abuse Act Reform
- Content Blocking
- Copyright Trolls
- Council of Europe
- Cyber Security Legislation
- Defend Your Right to Repair!
- Development Agenda
- Digital Books
- Digital Radio
- Digital Video
- DMCA Rulemaking
- Do Not Track
- E-Voting Rights
- EFF Europe
- Electronic Frontier Alliance
- Encrypting the Web
- Export Controls
- Fair Use and Intellectual Property: Defending the Balance
- FAQs for Lodsys Targets
- File Sharing
- Fixing Copyright? The 2013-2016 Copyright Review Process
- Free Speech
- Genetic Information Privacy
- Government Hacking and Subversion of Digital Security
- Hollywood v. DVD
- How Patents Hinder Innovation (Graphic)
- International Privacy Standards
- Internet Governance Forum
- Know Your Rights
- Law Enforcement Access
- Legislative Solutions for Patent Reform
- Locational Privacy
- Mandatory Data Retention
- Mandatory National IDs and Biometric Databases
- Mass Surveillance Technologies
- Medical Privacy
- Mobile devices
- National Security and Medical Information
- National Security Letters
- Net Neutrality
- No Downtime for Free Speech
- NSA Spying
- Offline : Imprisoned Bloggers and Technologists
- Online Behavioral Tracking
- Open Access
- Open Wireless
- Patent Busting Project
- Patent Trolls
- PATRIOT Act
- Pen Trap
- Policy Analysis
- Public Health Reporting and Hospital Discharge Data
- Reading Accessibility
- Real ID
- Reclaim Invention
- Search Engines
- Search Incident to Arrest
- Section 230 of the Communications Decency Act
- Social Networks
- SOPA/PIPA: Internet Blacklist Legislation
- State-Sponsored Malware
- Student Privacy
- Stupid Patent of the Month
- Surveillance and Human Rights
- Surveillance Drones
- Terms Of (Ab)Use
- Test Your ISP
- The "Six Strikes" Copyright Surveillance Machine
- The Global Network Initiative
- The Law and Medical Privacy
- TPP's Copyright Trap
- Trade Agreements and Digital Rights
- Trans-Pacific Partnership Agreement
- Travel Screening
- Trusted Computing
- UK Investigatory Powers Bill
- Video Games