This is part 1 of a series on the security of HTTPS and TLS/SSL
HTTPS is a lot more secure than HTTP! If a site uses accounts, or publishes material that people might prefer to read in private, the site should be protected with HTTPS.
Unfortunately, is still feasible for some attackers to break HTTPS. Leaving aside cryptographic protocol vulnerabilities, there are structural ways for its authentication mechanism to be fooled for any domain, including mail.google.com, www.citibank.com, www.eff.org, addons.mozilla.org, or any other incredibly sensitive service:
- Break into any Certificate Authority (or compromise the web applications that feed into it). As we learned from the SSL Observatory project, there are 600+ Certificate Authorities that your browser will trust; the attacker only needs to find one of those 600 that she is capable of breaking into. This has been happening with catastrophic results.
- Compromise a router near any Certificate Authority, so that you can read the CA's outgoing email or alter incoming DNS packets, breaking domain validation. Or similarly, compromise a router near the victim site to read incoming email or outgoing DNS responses. Note that SMTPS email encryption does not help because STARTTLS is vulnerable to downgrade attacks.
- Compromise a recursive DNS server that is used by a Certificate Authority, or forge a DNS entry for a victim domain (which has sometimes been quite easy). Again, this defeats domain validation.
- Attack some other network protocol, such as TCP or BGP, in a way that grants access to emails to the victim domain.
- A government could order a Certificate Authority to produce a malicious certificate for any domain. There is circumstantial evidence that this may happen. And because CAs are located in 52+ countries, there are lots of governments that can do this, including some deeply authoritarian ones. Also, governments could easily perform any of the above network attacks against CAs in other countries.
In short: there are a lot of ways to break HTTPS/TLS/SSL today, even when websites do everything right. As currently implemented, the Web's security protocols may be good enough to protect against attackers with limited time and motivation, but they are inadequate for a world in which geopolitical and business contests are increasingly being played out through attacks against the security of computer systems.
How often are these attacks occurring?
[Update 10/27/2011: there was an error in our manual de-duplication of CA organizations. Rather than 15 total compromised organizations and 5 since June, the CRLs indicate 14 total and 4 since June]
At USENIX Security this year, Jesse Burns and I reported a number of findings that came from studying all of the Certificate Revocation Lists (CRLs) that are published by CAs seen by the SSL Observatory.
One interesting feature of X.509 Certificate Revocation Lists is that they contain fields explaining the reason for revocations. As of last week, a scan of all the CRLs seen previously by the Observatory showed the following tallies:
+------------------------+------------+ | reason | occurences | +------------------------+------------+ | NULL | 921683 | | Affiliation Changed | 41438 | | CA Compromise | 248 | | Certificate Hold | 80371 | | Cessation Of Operation | 690905 | | Key Compromise | 73345 | | Privilege Withdrawn | 4622 | | Superseded | 81021 | | Unspecified | 168993 | +------------------------+------------+
The most interesting entry in that table is the "CA compromise" one, because those are incidents that could affect any or every secure web or email server on the Internet. In at least 248 cases, a CA chose to indicate that it had been compromised as a reason for revoking a cert. Such statements have been issued by 14 distinct CA organizations. A previous scan, conducted in June this year, showed different numbers:
+------------------------+------------+ | reason | occurences | +------------------------+------------+ | NULL | 876049 | | Affiliation Changed | 27089 | | CA Compromise | 55 | | Certificate Hold | 52786 | | Cessation Of Operation | 700770 | | Key Compromise | 59527 | | Privilege Withdrawn | 4589 | | Superseded | 66415 | | Unspecified | 174444 | +------------------------+------------+
Those "CA Compromise" CRL entries as of June were published by 10 distinct CAs. So, from this data, we can observe that at least 4 CAs have experienced or discovered compromise incidents in the past four months. Again, each of these incidents could have broken the security of any HTTPS website.
It is also interesting to examine revocations by reason as a function of time:
👁 CRL revocations grouped by reason
Generally, this plot reflects enormous growth in HTTPS/TLS deployment, as well as the growing strain that its being placed on its authentication mechanisms. The problems with the CA system and TLS authentication are urgent and structural, but they can be fixed. In this series of posts, we will set out an EFF proposal for reinforcing the CA system, which would allow security-critical websites and email systems to protect themselves from being compromised via an attack on any CA in the world.
