Sicherheit von SSL

Peter Ecklersley von der Electronic Frontier Foundation sagt, dass in den letzten vier Monaten mindestens fünf Certificate Authorities (CAs) kompromittiert wurden. Als Grundlage für diese Äußerung zog er die Sperrlisten für Zertifikate heran.

Heise (Quelle):

Diese sogenannten Certificate Revocation Lists (CRL) enthalten Zertifikate, die nicht mehr als gültig erachtet werden sollen. Herausgeber sperren Zertifikate aus verschiedenen Gründen – etwa weil der Kunde einen Geschäftsbereich aufgegeben hat (Cessation of operation) oder ihm der geheime Schlüssel abhanden kam (Key Compromise). Spannend sind die insgesamt 248 Fälle, in denen der der Herausgeber der CRL als Begründung angab, dass die zuständige Certificate Authority kompromittiert wurde. Bis Juni 2011 war das nur bei 55 Zertifikaten der Fall. Diese fast zweihundert, zwischenzeitlich gesperrten Zertifikate wurden von fünf verschiedenen CAs ausgestellt.

Fazit: Wenn mindestens fünf CAs innerhalb von nur 4 Monaten geknackt werden konnten, um missbräuchlich falsche Zertifikate auszustellen, dann kann mal wohl kaum von Sicherheit sprechen.

Um es metaphorisch auszudrücken: Wenn ich meine Papiere in einem Safe einschließe, sind diese eigentlich sicher. Wenn ich den Schlüssel vor die Eingangstüre lege, jedoch nicht!

Peter Ecklersley (Quelle):

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:

1. 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.
2. 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.
3. 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.
4. Attack some other network protocol, such as TCP or BGP, in a way that grants access to emails to the victim domain.
5. 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.