Welche Art von Angriffen verhindert SSL?

SSL/TLS verhindert Abhören, Manipulation und Identitätsdiebstahl durch Verschlüsselung der Daten während der Übertragung und Überprüfung der Serveridentität mittels eines digitalen Zertifikats. Allerdings bleiben falsch konfigurierte oder veraltete Implementierungen anfällig für bestimmte Downgrade- und Protokollangriffe.

SSL/TLS verhindert, dass Angreifer Daten während der Übertragung lesen oder verändern und sich als vertrauenswürdiger Server ausgeben. Es schützt vor Abhören, Man-in-the-Middle-Angriffen und Datenmanipulation. Protokollbasierte Angriffe wie POODLE, FREAK oder Logjam, die veraltete Versionen, schwache Verschlüsselungsalgorithmen oder Fehlkonfigurationen ausnutzen, anstatt die Verschlüsselung direkt zu knacken, werden jedoch nicht automatisch verhindert.

Wichtige Erkenntnisse

• TLS 1.3, definiert in RFC 8446, ist der aktuelle Sicherheitsstandard. SSL und TLS 1.0/1.1/1.2 sind veraltet; ältere Versionen bleiben anfällig für Downgrade-Angriffe wie POODLE.
• Die meisten benannten SSL/TLS-Angriffe nutzen die Konfiguration aus, nicht das Protokoll selbst. POODLE, FREAK, Logjam und DROWN setzen alle einen Server voraus, der neben TLS 1.3 noch veraltete Protokolle oder schwache Verschlüsselungssammlungen unterstützt.
• Fehler im Zertifikatslebenszyklus verursachen ebenso viele Vorfälle wie Protokollangriffe. Abgelaufene, selbstsignierte oder nicht widerrufene kompromittierte Zertifikate schaffen Einfallstore für Man-in-the-Middle-Angriffe, die nichts mit dem TLS-Handshake selbst zu tun haben.
• Wildcard-Zertifikate sollten keine sensiblen Subdomains abdecken. Ein einziger kompromittierter Wildcard-Schlüssel kann alle von ihm abgedeckten Subdomains offenlegen, einschließlich Anmelde- und Zahlungsseiten.
• Durch die Deaktivierung der Unterstützung für ältere Protokolle werden die meisten bekannten Angriffsvektoren geschlossen. Die ausschließliche Unterstützung von TLS 1.2 und TLS 1.3 mit modernen Verschlüsselungssammlungen eliminiert POODLE, FREAK, Logjam und BEAST als mögliche Angriffe.

SSL gegen TLS

TLS ist der direkte Nachfolger von SSL, und TLS 1.3 ist die aktuellste und sicherste Version, die heute weit verbreitet ist.

TLS 1.3 ist in RFC 8446 definiert und schützt den Handshake selbst vor Downgrade-Angriffen, die frühere Versionen betrafen. SSL und TLS 1.0/1.1 gelten aufgrund bekannter Sicherheitslücken in den gängigen Browsern als veraltet. TLS 1.2 wird zwar weiterhin unterstützt, aber zugunsten von TLS 1.3 schrittweise ersetzt.

Häufige SSL/TLS-Angriffe und wie sie abgemildert werden

Sechs namentlich genannte Angriffe machen den Großteil der historischen SSL/TLS-Exploitationstechniken aus, und für jeden gibt es eine spezifische, gut dokumentierte Lösung.

Attacke	Was es ausnutzt	Mitigation
PUDEL	SSLv3-Padding-Oracle-Schwachstelle	SSLv3 deaktivieren; nur TLS 1.2 oder höher unterstützen
FREAK	Schwache RSA-Verschlüsselungssuiten für den Export	Unterstützung für Export-Verschlüsselungssuiten deaktivieren
Logjam	512-Bit-Diffie-Hellman-Gruppen in Exportqualität	Diffie-Hellman-Verschlüsselungssuiten für den Export deaktivieren
ERTRINKEN	Server, die noch SSLv2 unterstützen	Stellen Sie sicher, dass private Schlüssel niemals auf SSLv2-fähigen Servern verwendet werden.
Sweet32	64-Bit-Blockchiffren im CBC-Modus	Deaktivieren Sie veraltete 64-Bit-Verschlüsselungsverfahren wie DES und 3DES.
TIER	Implementierungsfehler von CBC in TLS 1.0	Verwenden Sie Browser und Server, die TLS 1.1 oder höher unterstützen.

Jeder dieser Angriffe zielt auf ein bestimmtes Merkmal eines älteren Protokolls oder eine schwache Verschlüsselungssuite ab, anstatt TLS 1.3 direkt zu knacken. Deshalb werden die meisten dieser Angriffe gleichzeitig durch Deaktivierung der Unterstützung für ältere Protokolle behoben.

Angriffe, die die Zertifikatsverwaltung ausnutzen, nicht das Protokoll.

Man-in-the-Middle-Angriffe sind häufiger erfolgreich durch Fehler im Zertifikatsmanagement als durch einen Fehler im TLS-System selbst.

• Selbstsignierte Zertifikate in Produktion. Ein selbstsigniertes Zertifikat besitzt keine unabhängige Gültigkeit und sollte auf Testumgebungen beschränkt bleiben, niemals jedoch in Produktionssystemen verwendet werden.
• Nicht widerrufene, kompromittierte Zertifikate. Ein Zertifikat, das nach einer Schlüsselkompromittierung hätte widerrufen werden müssen, bleibt für einen Angreifer so lange nutzbar, bis es tatsächlich widerrufen und nicht nur ersetzt wird.
• Nicht vertrauenswürdige oder unbekannte Zertifizierungsstellen. Zertifikate von unbekannten, nicht geprüften Zertifizierungsstellen bergen ein Risiko, falls diese Zertifizierungsstelle später kompromittiert oder missbraucht wird.
• SSL-Stripping und Session-Hijacking. Bei diesen Angriffen wird der Benutzer durch eine Verwechslung mit einer unverschlüsselten Verbindung oder durch den Diebstahl einer aktiven Sitzungs-ID dazu verleitet, anstatt die Verschlüsselung direkt anzugreifen; HSTS und sichere Cookie-Flags sind die Standardverteidigungsmaßnahmen.

Reduzierung der Angriffsfläche für SSL/TLS

Mit wenigen Konfigurationseinstellungen lässt sich der größte Teil der oben beschriebenen Angriffsfläche schließen.

• Vermeiden Sie Wildcard-Zertifikate auf sensiblen Subdomains. Verwenden Sie separate Zertifikate für Login-, Zahlungs- und Admin-Subdomains, damit ein einzelner kompromittierter Schlüssel nur eine begrenzte Reichweite hat.
• Vermeiden Sie unbekannte oder nicht vertrauenswürdige Zertifizierungsstellen. Identifizieren Sie alle verwendeten Zertifizierungsstellen und ersetzen Sie Zertifikate unbekannter Herkunft durch Zertifikate vertrauenswürdiger, geprüfter Zertifizierungsstellen.
• Halten Sie die Zertifikatslebenszyklen aktuell. Abgelaufene Zertifikate zählen weiterhin zu den häufigsten Ursachen sowohl von Stromausfällen als auch von Man-in-the-Middle-Angriffen.
• HSTS aktivieren. HTTP Strict Transport Security zwingt Browser zur Verwendung von HTTPS Standardmäßig wird die anfängliche unverschlüsselte Anfrage, von der das SSL-Stripping abhängt, abgebrochen.

Angriffe auf SSL/TLS-Sicherheitslücken

Wie bei anderen Protokollen gibt es auch bei SSL/TLS-Protokollen Schwachstellen. Nachfolgend finden Sie Angriffe, die SSL/TLS 1.2 und ältere Versionen betreffen.

• BEAST-Angriff

  BEAST-Angriffe (Browser Exploit Against SSL/TLS) betreffen SSL 3.0 und TLS 1.0, indem sie die Sicherheitslücke (CVE-2011-3389) ausnutzen. Bei diesem Angriff kann der Angreifer eine Sicherheitslücke in der Implementierung von CBC (Cipher Block Chaining) in TLS 1.0 ausnutzen. Dies ermöglicht dem Angreifer, die verschlüsselten Daten zwischen zwei Benutzern/Systemen zu entschlüsseln, indem er die manipulierten Pakete mithilfe von MITM-Techniken in TLS-Streams einschleust.

  Diese Techniken ermöglichen es dem Angreifer, den für die eingeschleuste Nachricht verwendeten Initialisierungsvektor zu erraten. Anschließend kann er die Ergebnisse mit denen im zu entschlüsselnden Block vergleichen. Dieser Angriff erfordert Zugriff auf den Browser des Clients (Opfers). Um diesen Angriff erfolgreich auszuführen, kann der Angreifer in der Anfangsphase andere Angriffsvektoren verwenden. Verwenden Sie zur Abwehr dieses Angriffs Browser, die TLS 1.1 oder höher unterstützen.

• Kriminalität Angriff

  Bei CRIME-Angriffen (Compression Ratio Info Leak Made Easy) wird der Mechanismus von Komprimierungsalgorithmen ausgenutzt, der unter die Sicherheitslücke (CVE-2012-4929) fällt. In der Regel wird die Komprimierungsmethode in die Server-Hello-Nachricht als Antwort auf die Client-Hello-Nachricht eingefügt, um den Bandbreitenbedarf für den Datenaustausch zu reduzieren. Um diesen Prozess zu erleichtern, sendet der Server die „Komprimierungsmethode“ (am häufigsten wird DEFLATE verwendet) an den Client, während der Server die Komprimierungsmethode „NULL“ an den Client sendet, wenn keine Komprimierung erforderlich ist.

  Eine der wichtigsten Techniken von Komprimierungsalgorithmen besteht darin, die wiederholten Bytefolgen in der Nachricht durch einen Zeiger auf die erste Instanz dieser Folge zu ersetzen. Je länger die wiederholten Folgen sind, desto höher ist die Komprimierungsrate. Um diesen Angriff zu verhindern, verwenden Sie Ihren Browser, der das neueste TLS-Protokoll (TLS 1.3) unterstützt.

• BREACH-Angriff

  Der BREACH-Angriff (Browser Reconnaissance and Exfiltration via Compression of Hypertext) zielt darauf ab, den Komprimierungsmechanismus von HTTP statt TLS auszunutzen, wie es bei CRIME-Angriffen der Fall ist. Diese Sicherheitslücke ist in der NIST NVD-Datenbank als CVE-2013-3587 aufgeführt. Sie kann auch bei deaktivierter TLS-Komprimierung ausgenutzt werden. Dies geschieht, indem der Datenverkehr des Client-Browsers (Opfer-Browsers) auf eine TLS-fähige Drittanbieter-URL umgeleitet und der Datenverkehr zwischen Server und Client mithilfe von MITM-Angriffstechniken überwacht wird. Webserver, die HTTP-Komprimierung verwenden, spiegeln Benutzereingaben/Geheimnisse in HTTP-Antworttexten wider und sind daher anfällig dafür. Um diese Sicherheitslücke zu schließen, können Sie die Komprimierung auf HTTP-Ebene deaktivieren, Geheimnisse von Benutzereingaben trennen und Geheimnisse maskieren.

• HEARTBLEED-Angriff

  Heartbleed war ein kritischer Angriff, der die Sicherheitslücke in der Heartbeat-Erweiterung der OpenSSL-Bibliothek aufdeckte und in der NIST NVD-Datenbank unter der Nummer CVE-2014-0160 aufgeführt ist. Die Heartbeat-Erweiterung wird verwendet, um eine Verbindung aufrechtzuerhalten, solange beide Parteien noch aktiv sind.

  Lassen Sie uns die Heartbleed-Funktionalität in der OpenSSL-Bibliothek verstehen. Der Client sendet die Heartbeat-Nachricht mit den Daten und der Größe an den Server. Der Server antwortet dann mit den vom Client empfangenen Daten und der Größenangabe. Die Heartbleed-Sicherheitslücke zielte darauf ab, die Tatsache auszunutzen, dass der Server, wenn der Client eine falsche Datenlänge an den Server sendet, mit zufälligen Daten aus seinem Speicher antwortet, um die vom Client angegebene Längenanforderung zu erfüllen.

  Die zufälligen, unverschlüsselten Daten aus dem Serverspeicher können kritische Informationen wie private Schlüssel, Kreditkartendaten und andere sensible Daten enthalten. Um die Heartbleed-Sicherheitslücke zu schließen, aktualisieren Sie entweder auf die neueste Version der OpenSSL-Bibliothek oder kompilieren Sie die installierte Version mit dem Flag „DOPENSSL_NO_HEARTBEATS“ neu.

Wie schützt man sich vor SSL-Angriffen?

Wie in den obigen Abschnitten zu einigen häufigen SSL-Angriffen erläutert, ist es wichtig, dass Unternehmen ihre Sicherheitsrichtlinien zum SSL-Schutz überprüfen. Die bloße Implementierung von SSL oder TLS gewährleistet nicht die Sicherheit Ihrer Infrastruktur und Ihres Unternehmens. Vielmehr müssen die entsprechenden Richtlinien, Prozesse und Verfahren zur Risikominimierung umgesetzt werden. Darüber hinaus stehen auf dem Markt zahlreiche Techniken und Tools zur Verfügung, um Ihr Unternehmen zu schützen. Die Auswahl dieser Tools/Sicherheitsprodukte hängt jedoch von der Art und den Sicherheitszielen Ihres Unternehmens ab und sollte nach gründlicher Prüfung aller Sicherheitsaspekte erfolgen.

Wie kann Verschlüsselungsberatung helfen?

CertSecure Manager reduziert das SSL/TLS-Risiko im Zusammenhang mit der Zertifikatsverwaltung durch die Automatisierung von Erkennung, Widerruf und Erneuerung. So wird verhindert, dass abgelaufene, selbstsignierte oder nicht widerrufene Zertifikate in Produktionsumgebungen verbleiben. Die Encryption Advisory Services von Encryption Consulting analysieren die Protokoll- und Cipher-Suite-Konfiguration, um die verbleibende Angriffsfläche für Downgrades und Legacy-Protokolle zu schließen. Die Services basieren auf ISO/IEC 27001:2022- und SOC 2-zertifizierten Verfahren.

Häufig gestellte Fragen

Macht SSL/TLS eine Website absolut sicher?

Nein. SSL/TLS verschlüsselt zwar Daten während der Übertragung und verifiziert die Serveridentität, bietet aber keinen Schutz vor allen Bedrohungen. Fehlkonfigurierte Server, abgelaufene oder nicht widerrufene Zertifikate, schwache Verschlüsselungsalgorithmen und Sicherheitslücken auf Anwendungsebene sind auch bei aktiviertem TLS weiterhin möglich.

Was ist der Unterschied zwischen SSL und TLS?

TLS ist das Nachfolgeprotokoll von SSL, und der Name änderte sich, als SSL 3.0 auf TLS 1.0 aktualisiert wurde. SSL und TLS 1.0/1.1 gelten aufgrund bekannter Sicherheitslücken als veraltet; TLS 1.3, definiert in RFC 8446, ist der aktuelle Standard.

Warum stellen Wildcard-Zertifikate ein Sicherheitsrisiko dar?

Ein Wildcard-Zertifikat verwendet einen einzigen privaten Schlüssel für alle abgedeckten Subdomains. Wird dieser Schlüssel kompromittiert, sind alle Subdomains gleichzeitig gefährdet. Für sensible Subdomains wie Anmelde- oder Zahlungsseiten sollten daher individuelle Zertifikate verwendet werden.

Kann ein abgelaufenes Zertifikat zu einem Man-in-the-Middle-Angriff führen?

Ja. Organisationen, die den Lebenszyklus von Zertifikaten nicht ordnungsgemäß verwalten, können mit kompromittierten oder abgelaufenen Zertifikaten dastehen, die nie widerrufen wurden. Ein Angreifer kann ein solches Zertifikat weiterhin verwenden, um Vertrauen zu einer kompromittierten Website herzustellen und den verschlüsselt aussehenden Datenverkehr abzufangen.

Was ist HSTS und warum ist es für die SSL/TLS-Sicherheit wichtig?

HTTP Strict Transport Security (HSTS) weist Browser an, Verbindungen stets über HTTPS herzustellen und verhindert so die anfängliche unverschlüsselte Anfrage, auf der SSL-Stripping-Angriffe basieren. Dazu ist das Hinzufügen eines speziellen Antwortheaders erforderlich. HSTS zählt zu den effektivsten und einfachsten Schutzmaßnahmen gegen Downgrade-Angriffe.

Schließen Sie Ihre SSL/TLS-Angriffsfläche.

Sehen Sie sich CertSecure Manager in Aktion an, um Zertifikate aktuell zu halten und rechtzeitig zu widerrufen, oder sprechen Sie mit einem Berater von Encryption Consulting über Ihre TLS-Konfiguration.