Transport Layer Security richtig konfigurieren

Transport Layer Security richtig konfigurieren

Michael Schneider
von Michael Schneider
Lesezeit: 13 Minuten

Transport Layer Security (TLS) und dessen Vorgänger Secure Sockets Layer (SSL) sind Verschlüsselungsprotokolle zur sicheren Kommunikation im Internet. TLS wird vor allem zur Verschlüsselung der Kommunikation von Webseiten mittels HTTP eingesetzt, kann aber auch mit Protokollen wie POP3, SMTP, IMAP, XMPP oder FTP verwendet werden. Der Sicherheitslevel einer solchen verschlüsselten Verbindung hängt davon ab, welche Protokolle, Einstellungen und Cipher Suites eingesetzt werden. Beim Aufbau einer TLS-Verbindung handeln die beteiligten Systeme aus, welches Protokoll und welche Cipher Suite verwendet werden. In der TLS-Konfiguration werden die zu verwendenden Protokolle und Cipher Suites definiert und festgelegt, welche bevorzugt werden.

Wir stellen im Rahmen unserer Sicherheitsüberprüfungen regelmässig fest, dass die Konfiguration der Systeme den Anforderungen an eine sichere Verbindung nicht genügen. Dieses Labs beschreibt die Grundlagen einer sicheren TLS-Konfiguration und zeigt auf, wie diese überprüft werden kann.

TLS-Konfiguration

Die TLS-Konfiguration eines Systems besteht aus drei Teilen: Konfiguration (z.B. unterstützte Protokolle), Cipher Suites sowie das Zertifikat. Je nach Betriebssystem, Bibliothek oder Applikationssoftware unterscheidet sich die Konfiguration. Diese kann mittels Konfigurationsdateien, Windows Registry oder über eine grafische Oberfläche vorgenommen werden. Die Empfehlungen in diesem Labs lassen sich mit den meisten gängigen Lösungen umsetzen. Eine Übersicht über TLS-Konfiguration im Allgemeinen bietet das Dokument SSL/TLS Deployment Best Practices von Ivan Ristić.

Für TLS/SSL existieren fünf Protokolle:

Das Protokoll SSLv2 ist unsicher und sollte in jedem Fall deaktiviert werden. SSLv3 wurde seit 1996 nicht mehr aktualisiert, gilt als obsolet und wurde im Jahr 1999 durch TLSv1.0 als Standardversion abgelöst. Am 14. Oktober 2014 wurde die Schwachstelle POODLE (CVE-2014-3566) veröffentlicht, die einen Fehler in SSLv3 ausnutzt, um Informationen aus einer verschlüsselten Verbindung zu extrahieren. Die einzige wirkungsvolle Gegenmassnahme ist zurzeit die Deaktivierung von SSLv3.

Das Protokoll TLSv1.2 sollte als Hauptprotokoll eingesetzt und allen anderen Protokollen gegenüber bevorzugt behandelt werden. Die Protokolle TLSv1.0 und TLSv1.1 müssen vor allem aus Gründen der Abwärtskompatibilität weiterhin unterstützt werden.

Nebst der Auswahl der unterstützten Protokolle ist die Unterstützung respektive das Deaktivieren von Funktionen für einen sicheren Betrieb einer TLS-Infrastruktur relevant. Die Funktion Client-Initiated Renegotiation sollte deaktiviert werden, da diese eine Denial of Service Attacke gegen die TLS-Infrastruktur vereinfacht. Im September 2012 stellten die Security Researcher Juliano Rizzo und Thai Duong die Attacke CRIME (CVE-2012-4929) vor, die es ermöglicht sensitive Informationen (zum Beispiel ein Session-Cookie) aus einer TLS-Verbindung zu extrahieren. Die Gegenmassnahme dazu ist die Funktion TLS compression zu deaktivieren.

Beim Aufbau einer TLS-Verbindung wird zwischen Client und Server wird ein Sitzungsschlüssel für die Verschlüsselung der Kommunikation basierend auf einem Public-Key-Verfahren ausgehandelt. Wenn jemand eine solche Kommunikation einschliesslich des Handshakes aufgezeichnet hat, und später in den Besitz des Private Keys des Servers gerät, kann dieser Key dazu genutzt werden um die mitgeschnittene Kommunikation zu entschlüsseln. Die Funktion Forward Secrecy mitigiert diese Attacke, indem ein einmaliger Sitzungsschlüssel ausgehandelt wird, der im Nachhinein nicht vom Private Key des Servers abgeleitet werden kann. Für Forward Secrecy müssen die Cipher Suites des Schlüsselaustauschverfahrens Diffie-Hellman (DHE-RSA, DHE-DSS) und Elliptische Kurven basierend auf Diffie Hellman (ECDHE-RSA, ECDHE-ECDSA) eingesetzt werden.

Cipher Suites

Eine Cipher Suite setzt sich aus der Kombination von Algorithmen für die folgenden Elemente zusammen:

Eine aufgeschlüsselte Cipher Suite

Die Wahl der Cipher Suite für eine TLS-Verbindung hat einen grossen Einfluss auf die Sicherheit dieser Verbindung. Beim Aufbau einer Verbindung wird zwischen Server und Client die Cipher Suite ausgehandelt. Dementsprechend ist es wichtig, dass nur Cipher Suites durch die TLS Infrastruktur unterstützt werden, die einen definierten Sicherheitsstandard erfüllen. Es sollten nur Cipher Suites eingesetzt werden, die über eine Schlüssellänge von 128 Bit und mehr für die Algorithmen zur Authentifizierung und Verschlüsselung verfügen. Alle anderen Cipher Suites sind zu deaktivieren. Aus Sicherheitsgründen sollte dazu auch Triple DES (3DES) gezählt werden. 3DES verfügt zwar über eine Schlüssellänge von 168 Bit (3×56 Bit), aber aufgrund aus Erkenntnissen der Meet in the Middle Attacke sollte von einer effektiven Schlüssellänge von 112 Bit ausgegangen werden.

Im März 2013 fand ein Forschungsteam der Royal Holloway, TU Eindhoven und University of Illinois at Chicago eine Attacke gegen RC4 (CVE-2013-2566). Daher gelten auf RC4 basierende Cipher als unsicher und sollten auch nicht mehr eingesetzt werden. Im Jahr 2011 wurde die Verwendung von RC4 Ciphers als Gegenmassnahme für die Attacke BEAST (CVE-2011-3389) empfohlen. Für alle weit verbreiteten Web Browser sind Updates gegen diese Attacke veröffentlicht und daher kann der Einsatz von RC4 Ciphers deaktivieren werden.

Zertifikat

Das Zertifikat ist ein weiterer Bestandteil für eine sichere Konfiguration. Ein Zertifikat sollte alle eingesetzten Hostnamen/Domains im Feld Common Name (CN) oder als Subject Alternative Name (SAN) enthalten und von einer vertrauenswürdigen Zertifizierungsstelle signiert sein. Damit ein Zertifikat von einem Client auf Gültigkeit überprüft werden kann, muss das Zertifikat der Zertifizierungsstelle in allen Clients (z.B. Webbrowser), die auf das System zugreifen, hinterlegt und als vertrauenswürdig eingestuft sein. Bei der Generierung des Zertifikats gilt es zudem darauf zu achten, dass die Schlüssellänge des Private Keys mindestens 2048 Bit beträgt.

Bruce Schneier veröffentlichte am 05. Oktober 2012 einen Beitrag über die Sicherheit des Algorithmus SHA 1, und wies darauf hin, dass die Generierung von Kollisionen (Erstellung eines identischen Hashs mit verschiedenen Ursprungswerten) mit dem Einsatz von genügend Rechenleistung in den Bereich des Möglichen gerückt ist. Er kommt zum Schluss, dass nun die Ablösung von SHA1 durch SHA2/SHA3 beginnen sollte. Microsoft und Google kündigten ihrerseits an, dass Zertifikate mit SHA1 in Zukunft als weniger vertrauenswürdig eingestuft werden. Wenn ein neues Zertifikat ausgestellt wird, sollte dementsprechend SHA256 eingesetzt werden.

TLS-Konfiguration Checkliste

Die folgende Checkliste beinhaltet alle erwähnten Empfehlungen für eine sichere TLS-Konfiguration (Stand Oktober 2014):

TLS-Konfiguration überprüfen

Die eigene TLS-Konfiguration lässt sich mit verschiedenen Mitteln überprüfen. Das Qualys SSL Labs stellt einen SSL Server Test zur Verfügung, welcher laufend aktuellen Sicherheitsentwicklungen angepasst wird. Der Test liest die Konfiguration aus und bewertet diese anschliessend anhand von Best Practices. Ein Nachteil dieses Tests ist, dass nur öffentlich verfügbare Domains überprüft werden können, die Verwendung von IP-Adressen ist nicht erlaubt, zudem werden nur Tests auf den Port tcp/443 unterstützt.

Als Alternative können die Testschritte manuell mittels OpenSSL durchgeführt werden. Jerome Smith veröffentlichte eine Zusammenstellung von OpenSSL-Befehlen, mit denen eine TLS-Konfiguration überprüft werden kann. Mittels des Befehls openssl s_client -ssl3 -connect <ip-address>:<port> wird eine SSLv3 Verbindung aufgebaut und daraus können nun mehrere Informationen ausgelesen werden. Der Server im Beispiel verwendet das unsichere Protokoll SSLv3, als Cipher Suite wurde DHE-RSA-AES256-SHA ausgehandelt, die Funktion TLS compression wird unterstützt und ein Zertifikat mit einem Private Key von 1024 Bit verwendet. Bereits durch die Analyse eines Verbindungsaufbaus können so mehrere Schwächen in der Konfiguration identifiziert werden.

[user@host ~] openssl s_client -ssl3 -connect <ip-address>:<port>
CONNECTED(00000003)
...
---
SSL handshake has read 1020 bytes and written 369 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
...
---
closed

Um die Konfiguration von Cipher Suites zu überprüfen, kann mittels des Befehls openssl s_client -cipher NULL,EXPORT,LOW,3DES,RC4 -connect <ip-address>:<port> getestet werden, ob das System schwache Cipher Suites unterstützt. Die untenstehende Ausgabe zeigt, dass dies der Fall ist. Es wurde eine Verbindung mittels der Cipher Suite EDH-RSA-DES-CBC3-SHA aufgebaut.

[user@host ~] openssl s_client -cipher NULL,EXPORT,LOW,3DES,RC4 -connect <ip-address>:<port>
CONNECTED(00000003)
...
---
SSL handshake has read 1167 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression

Die manuelle Auswertung mit OpenSSL Befehlen ist nicht sonderlich effizient. Um zum Beispiel alle unterstützen Ciphers zu ermitteln, muss eine Abfrage mit jeder verfügbaren Cipher einzeln gesendet werden. Diese und weitere Überprüfungen lassen sich automatisieren. Es existieren Tools um eine TLS-Konfiguration zu kontrollieren. Eines dieser Tools ist SSLyze, das unter Windows, Mac OSX und Linux eingesetzt werden kann. SSLyze kann alle unterstützen Cipher Suites auslesen und listet den Status der Unterstützung für Funktionen wie Session Renegotiation oder TLS Compression auf.

PS C:\> .\sslyze.exe --regular <ip-address>:<port>
...
* Session Renegotiation:
  Client-initiated Renegotiations:   OK - Rejected
  Secure Renegotiation:              OK - Supported
* Deflate Compression:
  VULNERABLE - Server supports Deflate compression
...
* Certificate - Content:
  ...
  Signature Algorithm:               sha1WithRSAEncryption
  Key Size:                          1024 bit
  Exponent:                          65537 (0x10001)
...
* TLSV1 Cipher Suites:
  Preferred:
	DHE-RSA-AES256-SHA            DH-1024 bits   256 bits      HTTP 200 OK
  Accepted:
	DHE-RSA-AES256-SHA            DH-1024 bits   256 bits      HTTP 200 OK
	AES256-SHA                    -              256 bits      HTTP 200 OK
	DHE-RSA-AES128-SHA            DH-1024 bits   128 bits      HTTP 200 OK
	RC4-SHA                       -              128 bits      HTTP 200 OK
	RC4-MD5                       -              128 bits      HTTP 200 OK
	AES128-SHA                    -              128 bits      HTTP 200 OK
	EDH-RSA-DES-CBC3-SHA          DH-1024 bits   112 bits      HTTP 200 OK
	DES-CBC3-SHA                  -              112 bits      HTTP 200 OK

Im Gegensatz zum Qualys SSL Server Test müssen die erhaltenen Resultate teilweise selbst interpretiert und entsprechend eingestuft werden. In diesem Beispiel werden die folgenden Schwachpunkte identifiziert:

SSLyze ist im Gegensatz zum Qualys SSL Server Test nicht auf Domainnamen und Ports eingeschränkt. Es können IP-Adressen mit beliebigen Ports angegeben werden. Zusätzlich unterstützt SSLyze die Option STARTTLS und kann somit auch zur Überprüfung von Protokollen wie SMTP, POP3, IMAP, FTP, XMPP, LDAP oder RDP verwendet werden.

Zusammenfassung

Die Sicherheit einer TLS-Konfiguration hängt von der Auswahl der unterstützten Protokolle, Funktionen, Cipher Suites sowie einem korrekt ausgestellten Zertifikat ab. Die Standardeinstellungen einer Applikation entsprechen in vielen Fällen nicht den Anforderungen an eine sichere Konfiguration. Es lohnt sich diese Konfiguration zu überprüfen, um allfällig vorhandene Schwachpunkte zu identifizieren und anschliessend zu beheben.

Über den Autor

Michael Schneider

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Sie wollen mehr als einen simplen Security Test mit Nessus und Nmap?

Unsere Spezialisten kontaktieren Sie gern!

×
Bericht und Dokumentation

Bericht und Dokumentation

Michael Schneider

Einführung von CVSS v4.0

Einführung von CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Windows LAPS

Windows LAPS

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv