Cookies helfen uns bei der Bereitstellung unserer Dienste. Durch die Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies setzen.

SSL & TLS

„Transport Layer Security“ (TLS), häufig unter dem Namen des Vorgängers „Secure Sockets Layer“ (SSL), oder der häufigsten Verwendung, dem HTTPS-Protokoll, bekannt, ist ein zertifikatsbasiertes Verschlüsselungsprotokoll zur sicheren Übertragung von Daten im Internet. TLS ist nicht nur der de-facto-Standard für die sichere Übertragung von Website-Inhalten und -Eingaben, sondern wird zur Absicherung verschiedenster Protokolle und Dienste verwendet, beispielsweise E-Mail und (VoIP)-Telefonie.

Warum Zertifikate?

TLS schützt potenziell sensible Daten, die Besucher oder Kunden übertragen. Es verhindert aber auch Man-in-the-Middle-Angriffe, die ebenso auf sensible Daten abzielen können, oder die Darstellung falscher oder modifizierter Website-Inhalte ermöglichen.

Allein deshalb ist eine fehlende oder nicht korrekte Implementierung von TLS ein massives Sicherheitsproblem, selbst auf weniger „kritischen“ Seiten. Die zusätzliche Serverlast durch TLS ist mittlerweile vernachlässigbar, und mit Diensten wie Let’s Encrypt ist TLS kostenlos, schnell und einfach eingerichtet.

Surfen ohne HTTPS

Chrome markiert seit der Version 68 (Juli 2018) jede nicht über HTTPS übertragenen Website in der Adresszeile als „Nicht sicher“ (Quelle: https://blog.chromium.org/2018/02/a-secure-web-is-here-to-stay.html ). Firefox zeigte bereits einige Zeit zuvor Warnhinweise bei der Eingabe an, wenn sensible Formulardaten auf einer Website unverschlüsselt übertragen wurden. Dies bedeutet bei Verharren auf der Verwendung unverschlüsselter Websites, dass potenziellen Kunden und Besuchern schon beim Besuch der Website der Eindruck vermittelt wird, dass ein Unternehmen es mit der Sicherheit wohl nicht so genau nimmt – mit möglicherweise großen Auswirkungen auf Image und Kundenvertrauen.

Einrichten und Prüfen von TLS

Seit 2017 ist es durch Zertifizierungsstellen wie Let’s Encrypt ( https://letsencrypt.org/getting-started/ ) möglich, kostenlos von allen modernen Browsern akzeptierte TLS-Zertifikate ausstellen zu lassen, welche zudem einem hohen Sicherheitsstandard entsprechen. Hierfür gibt es für die verbreitetsten Webserver verschiedenste Tools, um das Ausstellen und Aktualisieren von Zertifikaten automatisiert und mit möglichst wenig Aufwand zu ermöglichen.

Der Dienst SSL Labs ( https://www.ssllabs.com/ ) ermöglicht es, die TLS-Konfiguration eines Servers zu prüfen und bietet Hinweise zur Verbesserung der Implementierung. Konfigurationsvorschläge und -generatoren finden sich beispielsweise unter https://ciphers.xyz oder bei Mozilla ( https://mozilla.github.io/server-side-tls/ssl-config-generator/ ), zum gründlicheren Verständnis bietet sich zusätzlich das Mozilla-Wiki ( https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations ) an.

Innerhalb einer internen Domäne empfiehlt es sich, die Aufgabe der Zertifizierungsstelle durch den Domänencontroller zu realisieren. Wichtig dabei ist, dass dieser an allen Geräten im internen Netzwerk als eine Vertrauensstelle eingetragen wird.

DNS CAA

Bei einem DNS-CAA-Eintrag handelt es sich um eine zusätzliche Sicherheitsmaßnahme. Seit dem 17. September 2017 sind dabei alle Zertifizierungsstellen verpflichtet, beim Ausstellen eines Zertifikats für eine (Sub-) Domain eine Prüfung des DNS-CAA-Eintrags durchzuführen. Sind einer oder mehrere solcher Einträge gesetzt, dürfen nur die gelisteten Zertifizierungsstellen entsprechende Zertifikate für die Domain oder Subdomains ausstellen. Dadurch soll verhindert werden, dass ein Angreifer über eine Zertifizierungsstelle vertrauenswürdige Zertifikate für eine fremde Domain ausstellen kann.

Es wird empfohlen, die DNS-CAA-Einträge für alle Domains und Subdomains zu konfigurieren, damit lediglich autorisierte Zertifizierungsstellen entsprechende Zertifikate ausstellen dürfen. Als hilfreicher Einstieg für das Einrichten der DNS-CAA-Einträge werden folgende Artikel empfohlen:

https://www.globalsign.com/de-de/blog/was-ist-caa

https://support.dnsimple.com/articles/caa-record

Schwachstellen

Aufgrund mangelhaften Pachtmanagements oder schlicht wegen einer möglichst hohen Abwärtskompatibilität unterstützen zahlreiche Server und Webanwendungen immer noch das veraltete Protokoll SSL. Die Variante SSLv2 wurde dabei bereits im Jahr 2011, SSLv3 im Jahr 2015 als unsicher eingestuft; beide sollten nicht mehr verwenden werden. Aber auch von der Verwendung von TLS 1.0/1.1 wird abgeraten, um dem PCI-Data-Security-Standard (DSS) zu entsprechen ( Quelle: https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls ).

Grund dafür ist, dass im Laufe der Zeit immer wieder Schwachstellen in den Verschlüsselungsmethoden gefunden und neue Techniken entwickelt werden, um diese auszunutzen. Generell empfiehlt es sich, die Zertifikate sowie die TLS/SSL-Konfiguration regelmäßig zu auditieren und die als unsicher geltende Protokolle zu deaktivieren. Dabei ist darauf zu achten, die Abwärtskompatibilität möglichst gering zu halten, um das Erzwingen schwacher Verschlüsselungsverfahren für die Kommunikation durch einen Angreifer zu minimieren. Zudem wurde in modernen Browsern, wie z.B. Chrome ≥ 40, SSLv3 auf Grund bekannter Schwachstellen vollständig deaktiviert.
Zur Überprüfung des Ist-Stands der eingesetzten Zertifikate hat sich die Seite https://globalsign.ssllabs.com bewährt .

POODLE Attack

Bei einem „POODLE“-Angriff wird die Abwärtskompatibilität des Webservers ausgenutzt um eine eigentlich sichere Verbindung auf ein älteres Protokoll herunter zu stufen. Gelingt es einem Angreifer während eines Man-in-the-Middle-Angriffs beispielsweise, die Verbindung auf SSLv3 abzustufen, kann die schwache Verschlüsselung ausgenutzt werden, um den Netzwerkverkehr Schritt für Schritt zu entschlüsseln ( Quelle: https://www.openssl.org/~bodo/ssl-poodle.pdf ).

Entscheidend bei dem Angriff ist, dass sowohl der Client als auch der Server die unsicheren Protokolle unterstützen müssen, damit diese erzwungen werden können.

DROWN Attack

Eine besonders kritische Sicherheitslücke stellt die sogenannte „DROWN Attack“ dar. Bei diesem Angriff werden Schwachstellen von SSLv2 ausgenutzt um die Verbindungen zwischen Client und Server zu entschlüsseln. Entscheidend dabei ist, dass der Client selbst SSLv2 nicht akzeptieren muss, sondern die Unterstützung durch den Server genügt. Das Besondere an dieser Angriffsmethode ist zudem, dass die Ausnutzung der Schwachstelle mit jedem Server/Dienst durchgeführt werden kann, auch wenn dieser nicht an der betroffenen Verbindung beteiligt ist. Der anzugreifende Server muss lediglich SSLv2 unterstützen und den selben privaten Schlüssel verwenden, welcher in der abgefangenen Kommunikation genutzt wurde.

Wird also beispielsweise ein Wildcard-Zertifikat an mehreren Servern eingesetzt, von denen mindestens einer SSLv2 unterstützt, kann dieser zum Entschlüsseln aller abgefangenen Netzwerkverbindungen genutzt werden, welche das selbe Zertifikat verwenden.

Um die Ausnutzung der „DROWN Attack“ zu unterbinden, muss die Unterstützung von SSLv2 auf allen Servern eingestellt werden, welche das Wildcard-Zertifikat verwenden. Am einfachsten ist dafür im Falle von OpenSSL ein Upgrade auf mindestens Version 1.0.1s bzw. 1.0.2g. Um langfristig Schwachstellen durch Sicherheitslücken und Fehlkonfigurationen zu vermeiden empfiehlt es sich jedoch, regelmäßige Aktualisierungen der Software und Überprüfungen der Konfigurationen durchzuführen.

Kann die Deaktivierung des unsicheren Protokolls aufgrund von Kompatibilitätsproblemen an den betroffenen Servern nicht realisiert werden, sollten für die ungesicherten Server individuelle SSL/TLS-Zertifikate eingesetzt werden, die unabhängig von dem Wildcard-Zertifikat sind. Dies behebt die Schwachstelle zwar nicht an den betroffenen Servern, verhindert jedoch, durch den Angriff eines betroffenen Servers die Kommunikation nicht für die „DROWN Attack“ anfälliger Server zu kompromittieren. ( Quelle: https://drownattack.com ).