Schwachstellen von SSL/TLS (Wie sicher ist SSL/TLS?)

SSL bzw. TLS ist das Standardverfahren zum Authentifizieren von Kommunikationspartner und das Verschlüsseln des Datentransports im Internet. Leider gibt es eine Reihe von Schwachstellen, die eine wirkungsvolle Authentifizierung und Verschlüsselung verhindern. Die Liste reicht von weit verbreiteten schwachen Implementierungen bis hin zu kompromittierten Zertifizierungsstellen. Das Ergebnis ist in der Regel, dass sich die Authentizität der verwendeten Zertifikate, die zur Authentifizierung von Servern verwendet werden, nicht gewährleisten lässt. Und somit auch keine wirkungsvolle Verschlüsselung der Kommunikation und der Daten möglich ist.
Kritische Zungen bezeichnen SSL/TLS und die damit verbundenen Systeme deshalb als "grundlegend defekt".

Übersicht: Schwachstellen von SSL/TLS

Bei den meisten Schwachstellen geht es gar nicht so sehr darum, dass die eingesetzten Verschlüsselungsverfahren nicht funktionieren, sondern dass es Möglichkeiten gibt, dass ein Angreifer eine wirkungsvolle Verschlüsselung verhindern oder die Daten auf Umwegen entschlüsseln kann.

Schwachstelle: Certification Authority (CA) / Zertifizierungsstelle

Die Zertifikate werden von weltweit über 700 Zertifizierungsstellen bzw. Certification Authoritys (CA) ausgestellt. Die Aussteller sind Dienstleister im Internet, die Zertifikate ausstellen und auch überprüfen. Die größte Schwachstelle von SSL bzw. TLS liegt bei den Zertifizierungsstellen.

Die Vertrauenswürdigkeit einer Certification Authority liegt im Ermessen der Software-Hersteller, die diese in ihre Listen mit aufnehmen. Als Nutzer hat man darauf meist gar keinen Einfluss, weil zum Beispiel ein typischer Browser per Default eine lange Liste "scheinbar" vertrauenswürdiger Root-CAs mitbringt.
Doch warum vertrauen Software-Hersteller CAs? Die CAs durchlaufen einen Audit-Prozess, bei dem sie auf Sicherheit und der Registrierprozess geprüft werden. Die CA muss den Hersteller davon überzeugen, dass sie vertrauenswürdig ist. Aber im Prinzip gibt es keine echte Kontrolle. Erst wenn etwas bekannt wird, verlieren die CAs das Vertrauen.
Umgekehrt kaufen viele Webhosting-Kunden ihre Zertifikate nicht direkt bei einer Zertifizierungsstelle, sondern bedienen sich bei Resellern oder den Angeboten von Hosting-Providern, die SSL-Verschlüsselung als Zusatzdienstleistung verkaufen. Das bedeutet, man hat nur bedingt Einfluss auf die Wahl der Zertifizierungsstelle.

Zertifizierungsstellen sind für Angreifer oft lohnende Angriffsziele und deshalb grundsätzlich einem nicht unerheblichen Risiko ausgesetzt. Wenn es einem Angreifer gelungen ist, Zugriff auf eine Zertifizierungsstelle zu bekommen, dann kann er sich beliebige Zertifikate erstellen.
Wenn das herauskommt, hilft nur noch, das Root-Zertifikat der Zertifizierungsstelle aus den Browsern und Betriebssystemen zu entfernen. Das stellt die nötige Sicherheit einigermaßen wieder her.

Schwachstelle: Zertifizierung / Zertifikatsausstellung

Grundsätzlich kann jede Zertifizierungsstelle Zertifikate für "jeden beliebigen Hostnamen" ausstellen. Deshalb kann es für jeden Hostnamen von unterschiedlichen Zertifizierungsstellen mehrere Zertifikate geben. Wenn eine Zertifizierungsstelle bei der Zertifikatsausstellung schlampig vorgeht, kann sich ein Angreifer ein gültiges Zertifikat für einen fremden Host ausstellen lassen.
Man kann davon ausgehen, dass es unter den Zertifizierungsstellen welche gibt, die "gültige Zertifikate für alles und jeden ausstellen". Dabei ist es egal, ob sie ihre internen Prozesse nicht im Griff haben, Geld verdienen wollen oder von einer staatlichen Stelle unter Druck gesetzt werden. Das bedeutet auch, dass CAs auf Anfrage für Regierungen oder Regierungsorganisationen Zertifikate ausstellen können, die für Abhöraktionen oder Man-in-the-Middle-Aktionen verwendet werden können. Für eine Man-in-the-Middle-Aktion ist ein solches Zertifikat notwendig, um einen Zertifikatsfehler auf der Client-Seite zu vermeiden. Mit diesen Zertifikaten geben sich dann zum Beispiel Geheimdienste und Ermittlungsbehörden als jemand anderer aus. Es gibt sogar die Möglichkeit Zweit- oder Wildcard-Zertifikate auszustellen.

Diese Zertifikate benötigt der Angreifer um im Rahmen eines Man-in-the-Middle-Angriffs die Verbindung zwischen Client und Server zu übernehmen und dem Client ein "gefälschtes" Zertifikat unterzuschieben. Da es gültig ist, nimmt der Client den Server als authentisiert an und akzeptiert die verschlüsselte Verbindung zum Man-in-the-Middle, der die verschlüsselten Daten entschlüsseln, mitlesen und sogar manipulieren kann.
Es gibt sogar Router, die initiierte SSL-Verbindungen übernehmen können. Für den Nutzer sieht das dann so aus, als ob er eine verschlüsselten Verbindung zum eigentlich kontaktierten Server hat. Dazwischen hängt jedoch der Router als Man-in-the-Middle, der die Daten unverschlüsselt an den Betreiber ausleitet.

Der Nutzer hat keine Möglichkeit zu prüfen, ob die CA den Zertifikate-Inhaber korrekt überprüft hat. Es gibt zwar drei verschiedene Arten von Zertifikaten, die unterschiedlich starken Prüfpflichten auferlegt sind. Leider gibt es keine Möglichkeit zu prüfen, ob diese Prüfpflichten auch tatsächlich eingehalten wurden. Das bedeutet, man muss der CA einfach vertrauen und darauf hoffen, dass das alles seine Ordnung hat.
Das bedeutet, das CA-Modell von SSL/TLS ist grundsätzlich kaputt. Warum? Weil es manipuliert und missbraucht werden kann. Für Abhörmaßnahmen, Man-in-the-Middle-Aktionen und Identitätsdiebstahl. Im Prinzip kann man einem Zertifikat, dass durch eine CA ausgestellt wurde überhaupt nicht vertrauen.

Schwachstelle: Herausgeber-Zertifikate / Fälschbarkeit von Zertifikatsketten

Systeme zur Gefahrenabwehr in Unternehmen, beispielsweise Viren-Scanner, Einbruchserkennung und Data Loss Prevention (DLP), untersuchen den Datenverkehr auf den Inhalt. Nahezu jeder Anbieter kann das auch bei verschlüsselten Verbindungen. Damit das gelingt, erhalten diese Anbieter von den Zertifizierungsstellen Intermediate-CA-Zertifikate (Herausgeber-Zertifikate). Für eine Man-in-the-Middle-Aktion ist ein solches Zertifikat notwendig, um einen Zertifikatsfehler auf der Client-Seite zu vermeiden.
Dazu überwachen DLP-Systeme verschlüsselte Verbindungen als Man-in-the-Middle. Bei einer für Verschlüsselung initiierten Verbindung, schiebt sich das DLP als Man-in-the-Middle in die Verbindung und weist sich mit einem Intermediate-Zertifikate als der kontaktierte Server aus.
Mit einem Intermediate-CA-Zertifikat können bliebige Identitäten beglaubigt und als Man-in-the-Middle verschlüsselte Verbindungen aufgebrochen werden. Doch dabei werden erfolgreiche Spionage- und Überwachungsangriffe begünstigt.
Um dem vorzubeugen hilft unter anderem CA-Pinning.

Schwachstelle: Schlüsselerzeugung

Bevor ein Server-Betreiber ein Zertifikat erhalten kann, muss er ein Schlüsselpaar, bestehend aus einem privaten und einem öffentlichen Schlüssel, erzeugen. Das Zertifikat erhält der Server-Betreiber dann, wenn er einen Antrag mit dem öffentlichen Schlüssel an eine Zertifizierungsstelle gestellt hat.

Nun gibt es einen zweifelhaften Service einiger Zertifizierungsstellen (Certification Authority, CA), die nicht nur das Zertifikat ausstellen, sondern auch gleich noch das Schlüsselpaar für den Kunden erzeugen. Sozusagen als Service für den Kunden. Besonders krass ist es, wenn der Kunde die Schlüssel per E-Mail zugeschickt bekommt. Einem unbedarften Kunden dürfte unter Umständen gar nicht auffallen, dass hier etwas schief gelaufen ist. Doch dieser private Schlüssel wurde auf einem fremden Rechner erzeugt und über fremde Netze übertragen. Und damit könnte ihn irgendjemand abgefangen oder aufgezeichnet haben. Unabhängig was danach mit dem privaten Schlüssel passiert, er ist jetzt nicht mehr geheim. Das Schlüsselpaar und das Zertifikat sind damit wertlos.

Grundsätzlich darf ein privater Schlüssel für die Entschlüsselung nicht einfach so übertragen werden. Und zum anderen darf das Schlüsselpaar nicht woanders erzeugt werden. Wenn bei der Erzeugung des Schlüssels dieser im Arbeitsspeicher und eventuell auf der Festplatte des fremden Rechners liegt, hat man überhaupt keinen Einfluss darauf. Woher will man wissen, dass mit diesem privaten Schlüssel kein Unfug getrieben wird?
Eine CA, die die privaten Schlüssel für ihre Kunden erzeugt oder verwaltet, muss deutlich mehr Aufwand betreiben, um die Sicherheit der Daten zu gewährleisten, weil sie besonders attraktiv für Angreifer ist.

Deshalb gilt, ein Schlüsselpaar sollte am besten auf dem Rechner erzeugt werden, auf dem das Schlüsselpaar zum Einsatz kommen soll. Und auch nur dort darf es gespeichert sein. Alternativ kann das Schlüsselpaar auch auf dem Rechner des Administrators erzeugt werden und nach der Zertifizierung zusammen mit dem Zertifikat auf den Server übertragen werden. Allerdings nicht über das öffentliche Netz, sondern nur innerhalb des lokalen Netzwerks.
Benötigt der Kunde Hilfe bei der Schlüsselerzeugung, dann darf die Hilfe nur über eine Remote-Desktop-Verbindung erfolgen, damit der private Schlüssel auf dem Server des Kunden bleibt.

Schwachstelle: Kompromittierte Zertifikate

Die Verschlüsselung mit Zertifikat beinhaltet zwei Schlüssel. Der öffentliche Schlüssel, der mit dem Zertifikat verbunden ist und ein dazu passender privater Schlüssel, der niemals in fremde Hände gelangen darf. Wenn dem Besitzer eines Zertifikats der private Schlüssel gestohlen wird, dann muss das Zertifikat in eine Blacklist (Sperrliste) aufgenommen werden, damit die Validierungsstelle diesen Schlüssel bei einer Abfrage als ungültig erklären kann. Dazu muss der Diebstahl vom Besitzer des Zertifikats erkannt und gemeldet werden. Wenn nicht kann ein Angreifer, der den privaten Schlüssel besitzt, die verschlüsselten Daten entschlüsseln.
Weil die Validierungsstellen unter Umständen nicht sicher zu erreichen ist, nehmen die Browserhersteller ungültig gewordene Zertifikate auch in ihre browsereigenen Blacklisten auf.

Schwachstelle: Validierung / Prüfung der Zertifikate

Wenn Verschlüsselung und damit die Authentifizierung wirklich von Bedeutung, dann muss jedes Zertifikat einzeln geprüft werden. Normal ist jedoch, dass die Prüfung der Zertifikate automatisiert und unsichtbar vom Nutzer erfolgt. Der Nutzer verwendet zwar SSL bzw. TLS macht sich aber nicht die Mühe, die Identität des Servers, mit der eine verschlüsselte Verbindung besteht, tatsächlich zu prüfen. Nach dem Motte: Egal mit wem und wie, Hauptsache verschlüsselt.

Folgende Punkte sollten dazu führen, dass ein Zertifikat als ungültig erkannt wird und die Verbindung abgebrochen wird:

Gerade beim letzten Punkt wird gepfuscht. Häufig ist es so, dass ein Zertifikat als gültig akzeptiert wird, obwohl es nicht überprüft werden kann. Das heißt, manche Browser akzeptieren ein ungültiges Zertifikat auch dann, wenn sie keine Antwort von der Validierungsstelle/Zertifizierungsstelle bekommen (OCSP). Bei einer ausbleibenden Antwort wird die Verbindung aufgebaut und verschlüsselt, obwohl es überhaupt nicht sicher ist, dass man mit dem richtigen Server verbunden ist (fehlende Authentizität). In so einem Fall könnte die Verbindung durch eine Man-in-the-Middle-Aktion gesteuert werden und eine offensichtlich verschlüsselte Verbindung von einer dritten Person abgehört werden.

Schwachstelle: Optionale Verschlüsselung

Generell startet jeder Verbindungsaufbau unverschlüsselt. Über diese unsichere Verbindung vereinbaren die Kommunikationspartner eine verschlüsselte Verbindung. Wenn jetzt einer der beiden Kommunikationspartner kein SSL bzw. TLS beherrscht, dann wird die Verbindung unverschlüsselt hergestellt.
Das bedeutet, schaltet sich ein Angreifer zwischen die Kommunikationspartner und filtert den Wunsch zur Verschlüsselung heraus, dann kann er eine "unverschlüsselte Verbindung erzwingen", obwohl man den Wunsch nach einer verschlüsselten Verbindung hat.
Das Problem dabei ist, dass die Kommunikationspartner die Verschlüsselung nicht zwingend, sondern nur als Option annehmen. Konsequenterweise sollte es so sein, dass eine als verschlüsselt initiierte Verbindungsaufnahme zu einer verschlüsselten Verbindung führt oder abgebrochen wird.

Für HTTP gibt es HTTP Strict Transport Security, kurz HSTS. Darüber teilt der Webserver dem Browser mit, dass HTTP-Requests über eine verschlüsselte Verbindung erfolgen sollen.

Schwachstelle: Schwache Verschlüsselung

Beim SSL-Verbindungsaufbau teilt der Client dem Server eine Liste mit den unterstützten Verschlüsselungsverfahren mit. Normalerweise sollte der Server den ersten Vorschlag aus der Liste wählen, den auch er unterstützt. Hier sollte mindestens AES mit 128 Bit zum Einsatz kommen. Allerdings richten sich nicht alle Server danach, sondern bestimmen die Auswahl selber.
Oft genug werden die mit TLS/SSL verschlüsselten Verbindungen mit RC4 verschlüsselt. Obwohl RC4 aufgrund seines Alters als nicht besonders sicher gilt, wird es sehr häufig verwendet. Warum? Der Hauptgrund dürfte der geringe Bedarf an Rechenleistung beim Verschlüsseln und Entschlüsseln sein. Im Vergleich mit AES ist RC4 schneller und verbraucht weniger Rechenleistung.
Für die Betreiber vieler Server mit riesigen Datenmengen reicht die Verschlüsselung von RC4 vollkommen aus. Außerdem hat auch AES Schwächen. Es ist anfällig gegen BEAST-Angriffe, sofern die Client-Programmierer nicht vorgesorgt haben (TLS Version 1.2).

Verschlüsselung und Integrität

Wenn jemand eine Nachricht verschicken will, die nur der Empfänger und sonst niemand lesen können soll, dann sorgt man auch dafür, dass sie nicht verändert werden kann bzw. die Veränderung beim Empfänger erkannt wird. Das bedeutet, es wird verschlüsselt und die Integrität sicher gestellt. Für die Integrität wird ein sogenannter Message Authentication Code (MAC), typischerweise mit einer kryptografischen Hash-Funktion, erstellt. Dazu wird aus einem auf beiden Seiten bekannten Geheimnis ein Hash-Wert gebildet.

Nun gibt es an der Stelle die Frage, ob man zuerst verschlüsselt und dann den MAC bildet, oder ob man zuerst den MAC bildet und danach verschlüsselt. Nun ist es so, dass man festgestellt hat, dass es besser ist, wenn man zuerst verschlüsselt und dann den MAC bildet. TLS macht es aber genau anders herum. TLS erzeugt erst den MAC und verschlüsselt dann, was zu einigen Problemen und Fehlern geführt hat. Der IETF-Arbeitsgruppe von TLS ist das durchaus bekannt. Bisher ist es jedoch zu keiner Korrektur gekommen.

Schwachstelle: Software-Implementierung

Generell hängt die Sicherheit von Kryptographie und Verschlüsselung davon ab, dass zum einen die Verfahren sicher sind und zweitens die Verfahren korrekt angewendet werden. Krypto- und Verschlüsselungsalgorithmen korrekt zu benutzen ist aber nicht so ganz einfach. Dazu braucht es Hintergrundwissen und viel Erfahrung.
Um es sich einfacher zu machen nutzen viele Entwickler die unterschiedlichsten Software-Bibliotheken. Im Fall von SSL/TLS zum Beispiel JSSE, OpenSSL oder GnuTLS. Diese Bibliotheken bieten dem Programmierer eine Vielzahl von Optionen und Einstellungen, die bei einer ungünstigen Konstellation eine wirksame Verschlüsselung außer Kraft setzen können. Wenn diese Bibliotheken fehlerhaft genutzt werden ist die Verschlüsselung unwirksam.
Leider sind die Schnittstellen vieler Bibliotheken schlecht entwickelt und überfordern die Programmierer. Erschwerend kommt hinzu, dass es an vernünftigen Testmöglichkeiten für Programme fehlt, die SSL-Funktionen nutzen.
Das bedeutet, dass Programme und Anwendungen mit SSL-Verschlüsselung nicht zwangsläufig sicher sind. Unterschiedliche Studien haben gezeigt, dass die Überprüfung von Zertifikaten in vielen wichtigen Programmen und Bibliotheken nicht richtig funktioniert. Das öffnet Tür und Tor für Man-in-the-Middle-Angriffe. Das betrifft Online-Shops, Messaging-Dienste, Cloud-Dienste, Mobile-Apps, bis hin zu kritischen Geschäftsanwendungen, die sensible Kundendaten transportieren. Als Anwender hat man so gut wie keine Möglichkeit zu überprüfen, ob auch alles mit rechten Dingen zugeht. Hier hilft nur ein Blick in den Quellcode.

Schwachstelle: Heimlich nachinstallierte CA-Root-Zertifikate

Wer denkt, dass kommerzielle Software besser ist, der täuscht sich. Die Krypto-API von Windows zum Beispiel aktualisiert die Liste seiner Root- bzw. Stamm-Zertifikate dynamisch über einen Update-Mechanismus (nicht Windows-Update). Das heißt, kennt Windows ein Zertifikat nicht, aktualisiert es seine Liste im Hintergrund, ohne den Nutzer zu informieren. Dieser Vorgang gilt dann für das gesamte System und alle Software-Clients, die auf diese Krypto-API zurückgreifen. Dazu zählen der Internet Explorer, aber auch Chrome und Safari (nicht Firefox).
Das Problem dabei? Die heimlich nachinstallierten CA-Zertifikate. Das mag benutzerfreundlich sein. Aber ist es auch sicher? Besser wäre es, der Benutzer bekäme zumindest eine Sicherheitswarnung.
Schon jetzt kommen die Zertifikatslisten über Content Distribution Networks, beispielsweise Akamai. Denkbar wäre, dass sich Geheimdienste direkt über Microsoft oder über Umwege in den Zertifikatsspeicher als vertrauenswürdige Herausgeber importieren.

Fazit: Hohe Komplexität für den Normalnutzer

Für den Normalnutzer, der eine verschlüsselte Verbindung zu Online-Shops oder beim Online-Banking aufbaut, gibt es keine aussagekräftigen Prüfmechanismen, die notwendig wären, um einen Server vollständig zu authentisieren. Dafür sind die Vorgänge viel zu komplex und vielschichtig, als dass ein Normalnutzer fassen und beurteilen könnte.

Warum ist SSL/TLS unsicher?

Man kann SSL bzw. TLS als sicher ansehen. Doch ist es auch sicher genug? An SSL ist das CA-Modell der entscheidende Knackpunkt. Nahezu alle beschriebenen Schwachstellen hängen sich daran auf. Sehr häufig haben Sicherheitsprobleme bei SSL bzw. TLS mit dem CA-Modell zu tun. Dabei ist es wichtig zu verstehen, dass nicht SSL am Arsch ist, sondern das Vertrauensmodell auf deren Basis die Authentisierung erfolgt bzw. die Authentizität der Gegenstelle sichergestellt wird. Nur wenn dieser Vorgang wasserdicht ist, kann auch die Verschlüsselung wirksam sein. Da die Authentizität der Gegenstelle bei SSL/TLS nicht zweifelsfrei sichergestellt werden, weil die CAs, die Zertifizierung und die Validierung manipulierbar sind, ist jede noch so starke SSL/TLS-Verschlüsselung als unsicher anzusehen.
Jedem Anwender, der SSL bzw. TLS nutzt, und das tut jeder, der im Internet Verschlüsselung nutzt, muss klar sein, dass er mit einer gewissen Unsicherheit leben muss.

Was ist zu tun?

Betrachtet man die Schwachstellen von SSL bzw. TLS stellt sich die Frage, welcher zentralen Instanz man noch vertrauen kann? Wer kann mir als Anwender versichern, dass der Server den ich kontaktiert habe, wirklich der Server ist, den ich erreichen will? Welche Alternativen zum bisherigen CA-Modell gibt es?