Schwachstellen von SSL und TLS

Wie sicher ist SSL bzw. TLS?

SSL bzw. TLS ist das Standardverfahren zum Authentifizieren von Kommunikationspartner und das Verschlüsseln des Datentransports mit Anwendungsprotokollen im Internet. Leider hat das alte SSL und auch TLS 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.
Kritische Zungen bezeichnen SSL bzw. TLS und die damit verbundenen Systeme deshalb als "grundlegend defekt".

Hinweis: Obwohl man in der Regel TLS verwendet, ist das Vorgänger-Protokoll mit der Bezeichnung SSL immer noch üblich. Häufig werden beide Bezeichnungen synonym verwendet.

Übersicht: Schwachstellen von TLS

  • Certification Authority (CA) / Zertifizierungsstelle
  • Zertifizierung / Zertifikatsausstellung
  • Herausgeber-Zertifikate
  • Schlüsselerzeugung
  • Kompromittierte Zertifikate
  • Validierung / Prüfung der Zertifikate
  • Optionale Verschlüsselung
  • Schwache Verschlüsselung
  • Verschlüsselung und Integrität
  • Software-Implementierung
  • Heimlich nachinstallierte CA-Root-Zertifikate
  • Zu hohe Komplexität für den Normalnutzer

Bei den meisten Schwachstellen geht es gar nicht so sehr darum, dass die eingesetzten Verfahren nicht funktionieren, sondern dass es Möglichkeiten gibt, dass ein Angreifer eine wirkungsvolle Authentifizierung und Verschlüsselung verhindern 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 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 TLS-Verschlüsselung als Zusatzdienstleistung verkaufen. Das bedeutet, man hat nur bedingt Einfluss auf die Wahl der Zertifizierungsstelle.

Zertifizierungsstellen sind für bestimmte Angreifer lohnenswerte 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. Und zwar für jeden Webserver.
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, 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. Die haben

Diese Zertifikate benötigt der Angreifer um im Rahmen eines Man-in-the-Middle-Angriffs, um 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 TLS-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 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 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:

  • abgelaufener Gültigkeitszeitraum
  • unterschiedlicher Hostname im Zertifikat
  • unterbrochene Vertrauenskette zum CA-Root-Zertifikat

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 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 TLS-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 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).

Schwachstelle: 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 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 TLS-Funktionen nutzen.
Das bedeutet, dass Programme und Anwendungen mit TLS-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 TLS unsicher?

Man kann 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 TLS mit dem CA-Modell zu tun. Dabei ist es wichtig zu verstehen, dass nicht TLS 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 TLS nicht zweifelsfrei sichergestellt werden, weil die CAs, die Zertifizierung und die Validierung manipulierbar sind, ist jede noch so starke TLS-Verschlüsselung als unsicher anzusehen.
Jedem Anwender, der 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 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?

Um SSL sicherer zu betreiben führt ebenfalls kein Weg an TLS Verion 1.3 vorbei.

Weitere verwandte Themen:

Frag Elektronik-Kompendium.de

Netzwerktechnik-Fibel

Alles was Sie über Netzwerke wissen müssen.

Die Netzwerktechnik-Fibel ist ein Buch über die Grundlagen der Netzwerktechnik, Übertragungstechnik, TCP/IP, Dienste, Anwendungen und Netzwerk-Sicherheit.

Das will ich haben!

Artikel-Sammlungen zum Thema Netzwerktechnik

Collection: Netzwerk-Sicherheit

Was du über Netzwerk-Sicherheit wissen solltest.

eBook kaufen

Collection: Netzwerk-Grundlagen

Was du über Netzwerk-Grundlagen wissen solltest.

eBook herunterladen

Collection: IPv6

Was du über IPv6 wissen solltest.

eBook kaufen

Schützen Sie Ihr Netzwerk

TrutzBox

Die TrutzBox enthält einen leistungsstarken Content-Filter, der Werbetracker blockiert und vor Schadcode auf bösartigen Webseiten schützt.
Alle Internet-fähigen Geräte, egal ob Desktop-PCs, vernetzte Produktionsanlagen und IoT-Geräte, werden vor Überwachung durch Tracker, Einschleusen von Schadsoftware und dem unbedachten Zugriff auf bösartige Webseiten geschützt.

  • Sicheres Surfen mit Content-Filter und Blocker gegen Werbetracker
  • Mehrstufige Sicherheitsarchitektur mit Stateful-Inspection-Firewall und Intrusion-Prevention-System
  • Laufende Aktualisierung gegen neue Bedrohungen

Bestellen Sie Ihre TrutzBox mit integriertem Videokonferenz-Server jetzt mit dem Gutschein-Code "elko50" und sparen Sie dabei 50 Euro.

Mehr über die TrutzBox TrutzBox jetzt mit Gutschein-Code bestellen