Das Transport Layer Security (TLS)-Protokoll bildet die Basis von verschlüsselter Kommunikation in einer Vielzahl von Systemen. Am häufigsten wird von TLS im Zusammenhang mit HTTPS gesprochen, jedoch wird das Protokoll auch für Voice over IP (VoIP), E-Mail und Sofortnachrichtendienste verwendet. Das Vorgängerprotokoll Secure Socket Layer (SSL) wird oftmals gleichbedeutend verwendet, sollte aber inzwischen als obsolet angesehen werden.

Primäres Ziel des Protokolls ist es, eine private Kommunikation mit Datenintegrität zwischen zwei Parteien zu erlauben. Sicherheit der Kommunikation wird mittels symmetrischer Verschlüsselung gewährleistet. Der Schlüssel hierfür wird vor dem Austausch von Daten generiert und über ein sicheres Schlüsselaustauschprotokoll geteilt. Die Identität des Partners kann über die Verifikation der verwendeten Zertifikate sichergestellt werden. Herkömmlich wird die Identität des Servers hiermit bestätigt. Integrität der Pakete und somit Sicherheit, dass diese nicht verändert wurden, wird durch einen Nachrichtenauthentifizierungscode (Message Authentication Code, oder MAC) ermöglicht.

Warum HTTPS

Es gibt eine Vielzahl an Gründen, warum HTTPS für eine Kommunikation eingesetzt werden sollte statt Klartext HTTP. Durch die Verwendung von HTTPS bleiben URLs, Header sowie die Inhalte der übertragenen Seiten vertraulich. Man-in-the-Middle (MitM)-Angriffe werden theoretisch unmöglich gemacht, die Integrität der Inhalte wird gewährleistet. Eventuelle Manipulation des Datenverkehrs wird ebenfalls erkannt. Mit HTTP ohne SSL/TLS ist es einem Angreifer in der MitM-Position möglich, übertragene Daten auszulesen oder zu manipulieren. Das bedeutet auch, dass ein Angreifer Inhalte Ihrer Webseite verändern bzw. hinzufügen kann, unter anderem auch Schadcode. Moderne Browser markieren Webseiten ohne HTTPS deutlich als unsicher, was wiederum die Autorität Ihrer Internetpräsenz in Frage stellt. HTTPS bietet keinen Geschwindigkeitsnachteil, im Gegenteil, moderne Server erlauben sogar eine schnellere Verbindung mit HTTPS. Die Konfiguration ist unkompliziert und Zertifikate sind mittlerweile kostenfrei erhältlich (z.B. LetsEncrypt).

Zusätzlich zu den zahlreichen Vorteilen in Bezug auf die Sicherheit, die Integrität und die Verfügbarkeit des Dienstes kann HTTPS auch Vorteile für die Search Engine Optimization (SEO) bringen. Suchseiten wie Google beachten möglicherweise die Verfügbarkeit von HTTPS bei der Bewertung von Webseiten.

---

Der Verbindungsaufbau und die Kommunikation zwischen einem Client und einem Server verläuft in der Regel, vereinfacht dargestellt, folgendermaßen.

Schlüsselelemente

Die Sicherheit einer SSL/TLS-Kommunikation ist von einigen Schlüsselelementen abhängig. Je nach Konfiguration bietet die Kommunikation zusätzliche Eigenschaften, wie zum Beispiel den Schutz vor retrospektiver Entschlüsselung.

Protokoll

Das Protokoll definiert die grundsätzliche Kommunikation für die Verbindung und ist ebenso ausschlaggebend für eine sichere Verbindung wie das Verschlüsselungsprotokoll selbst. Aufgrund einer Serie an Schwachstellen (dazu später mehr) müssen die Protokolle SSL2 und SSL3 als Sicherheitslücke angesehen werden und sollten unter allen Umständen vermieden werden. Der Nachfolger von SSL3, TLS 1.0 sollte inzwischen auch vermieden werden, da das Protokoll eine Methode anbietet, eine aufgebaute TLS 1.0-Verbindung auf SSL3 herunterzustufen. Somit ist die Verbindung wieder anfällig gegenüber den Schwachstellen, die SSL3 betreffen. Aktuell sind TLS 1.1 und TLS 1.2 als sichere Protokolle empfohlen. Diese bieten eine Reihe an Verbesserungen, die eine sichere Verbindung gewährleisten. Das TLS 1.3, das sich zurzeit in einem funktionierendem Entwurfstadium befindet, wird zukünftig empfohlen.

Mit Version 1.3 werden weitere Sicherheitsmaßnahmen in das Protokoll integriert und veraltete Mechanismen entfernt. Außerdem wird mit dem neuen Protokoll versucht, den Verbindungsaufbau zu beschleunigen. Bei der Wahl des Protokolls und der Konfiguration ist die Zielgruppe des Dienstes zu beachten, da nicht alle Clients alle Protokolle unterstützen. Die Aushandlung des verwendeten Protokolls ist in der Grafik oben blau dargestellt.

Cipher suite

Die sogenannte Cipher Suite wird bei der Aushandlung von gemeinsam verwendeter Schlüsselaustauschmethode (Key Exchange Algorithm), Verschlüsselungsmethode mit entsprechendem Modus (Cipher) und einer Authentifizierungsmethode (Message Authentication Code Algorithm) verwendet. Bei dem Verbindungsaufbau wird von dem Client eine Liste an Cipher Suites mitgeschickt, die alle von dem Client unterstützten Methoden enthalten. Der Server antwortet daraufhin mit der Cipher Suite, die für die restliche Verbindung verwendet werden soll. Die Sicherheit der TLS-Verbindung ist von der gewählten Cipher Suite abhängig.

Mit TLS 1.3 verändert sich die Verwendung der Cipher Suite dahingehend, dass diese nur mehr für die Aushandlung von bestimmten Verschlüsselungsmethoden und Authentifizierungsmethoden verwendet wird. Hier werden die akzeptierten Methoden in Bezug auf deren Sicherheit weiter eingeschränkt. Für die Aushandlung der Schlüsselaustauschmethode werden TLS-Erweiterungen verwendet. Die Absprache über die gemeinsam verwendete Cipher Suite wird in der Grafik in Blau dargestellt.

Key Exchange/Authentication

Der Schlüsselaustausch wird verwendet, um eventuell Partien zu authentifizieren, sowie für den Austausch von Schlüsseln die Verschlüsselung der Mitteilung während der Verbindung verwendet wird. Die eventuelle Verifizierung der beiden Partien wird in der Grafik in Grün dargestellt. Hierfür werden die Zertifikate bei einer Zertifikatsbehörde geprüft. Der Schlüsselaustausch ist in der Grafik in Gelb dargestellt.

Empfohlen sind die Schlüsselaustauschmethoden Elliptic Curve Diffie-Hellman Ephemeral mit RSA für die Authentifizierung (ECDHE_RSA) und Diffie-Hellman Ephemeral mit RSA für die Authentifizierung (DHE_RSA).

Cipher

Der Cipher wird mit dem erzeugtem Masterschlüssel für die symmetrische Verschlüsselung der Pakete verwendet. Die Verwendung des Ciphers wird in der Abbildung in Violett repräsentiert. Für die symmetrische Verschlüsselung wird AES mit einer Schlüssellänge von 128 bits (AES128) oder 256 bits (AES256) empfohlen.

Modus

Der Betriebsmodus bezieht sich auf den gewählten Cipher und definiert, wie Nachrichten blockweise verarbeitet werden. Der Modus kann auch Quelle für Schwachstellen sein, beispielsweise durch standardisiertes Auffüllen auf bestimmte Blockgrößen (dazu später mehr). Der empfohlene Betriebsmodus ist der Galois/Counter Mode (GCM), da dieser die Eigenschaft „Authenticated Encryption with Associated Data“ (AEAD) bietet. Somit bietet die Verschlüsselungsmethode Vertraulichkeit, Integrität und Authentizität der übermittelten Daten.

Hashing Algorithmus

Der Hashing Algorithmus kommt möglicherweise für die Mitteilungsauthentifzierung zum Einsatz und findet Anwendung bei der Generierung des symmetrischen Schlüssels. Wird ein Cipher mit AEAD-Modus verwendet, so findet der Hashing-Algorithmus nur für die Generierung der Schlüssel Einsatz, in der Illustration dargestellt in Gelb. Alternativ wird der Hashing-Algorithmus für jede Nachricht eingesetzt, in der Grafik in Violett dargestellt. Der Hashing Algorithmus SHA2 (SHA256 oder SHA384) ist empfohlen.

Eigenschaften

Eine TLS-Verbindung kann zusätzliche wünschenswerte Eigenschaften besitzen. Diese können mit gezielter Konfiguration hervorgerufen werden.

Perfect Forward Secrecy (PFS)

Sollten zu einem Zeitpunkt die privaten Schlüssel einer TLS-Verbindung entwendet werden, so kann theoretisch die vergangene, aufgezeichnete Kommunikation entschlüsselt werden. Durch PFS wird eine retrospektive Entschlüsselung unmöglich gemacht. Um PFS zu verwenden, muss ein ephemeral Schlüsselaustausch, also DHE oder ECDHE genutzt werden.

TLS Fallback Signaling Cipher Suite Value (SCSV)

Um Herabstufungsangriffen auf eine sichere-TLS Verbindung entgegenzuwirken, wurde TLS Fallback SCSV eingeführt. Diese ist direkt von der eingesetzten SSL-Bibliothek abhängig, die auch aus diesem Grund aktuell gehalten werden soll.

Authenticated Encryption with Associated Data (AEAD)

Durch den Einsatz von Ciphern mit AEAD wird Authentisierung zu der Verschlüsselung von Daten hinzugefügt und somit wird die Manipulation von den Daten erkennbar gemacht. Der Einsatz von TLS 1.2 und Ciphern mit einem Modus der AEAD erlaub ist empfohlen, beispielsweise AES256-GCM.

Moderne Schwachstellen

Die Sicherheit einer TLS-Verbindung ist von ihrer Konfiguration und der darunterliegenden SSL-Bibliothek abhängig. Die Wichtigkeit der Aktualität der eingesetzten Software sowie einer zeitgemäßen Konfiguration wird immer wieder deutlich. Die folgenden modernen Schwachstellen sind lediglich ein Auszug aus einer langen Liste und unterstreichen die Dringlichkeit von korrekter Konfiguration.

Heartbleed

Eine fehlerhafte Eingabevalidierung in der SSL-Bibliothek OpenSSL, die häufig für TLS eingesetzt wird, führte dazu, dass Arbeitsspeicher am Server ausgelesen werden konnte. Die Schwachstelle wurde durch ein Update von OpenSSL behoben. Weiteres zum Thema Heartbleed hier.

POODLE

Das Akronym steht für „Padding Oracle On Downgraded Legacy Encryption“ und ist eine Man-in-the-Middle-Attacke, bei der eine TLS-Verbindung herabgestuft wird und somit für den Angreifer einsehbar ist. Um POODLE zu verhindern, sollte SSL3 deaktiviert werden. TLS Fallback SCSV wurde implementiert, falls ein Server unbedingt SSL3 unterstützen muss, aber sich trotzdem vor POODLE schützen will. Weiteres zum Thema POODLE hier.

Logjam

Die Logjam-Schwachstelle, oft auch WeakDH, betrifft den Diffie-Hellman Schlüsselaustausch mit 512 bis zu 1024 bit Schlüssellänge. Ein Angreifer ist möglicherweise in der Lage, die Kommunikation mitzulesen oder zu verändern. Um dies zu verhindern, muss DH mit mindestens 2048 bit verwendet werden. Weiters zum Thema Logjam hier.

Praktische Webserver-Konfiguration

Für die praktische Umsetzung werden die drei am weitesten verbreiteten Webserver besprochen, Apache, NGINX und IIS. Außer den Protokollen und der unterstützen Cipher Suites sind für Webserver einige weitere Einstellungen relevant. Hierzu zählt die Konfiguration von HTTP Strict Transport Security (HSTS) und anderen Headern.

HTTP Strict Transport Security (HSTS):

Mit aktivem HSTS Header wird ein Client (Browser) für einen definierten Zeitraum gezwungen, eine Webseite über HTTPS aufzurufen und Zertifikatwarnungen können nicht ignoriert werden. Der Zeitraum sollte auf mindestens 6 Monate (15.780.000 Sekunden) konfiguriert werden.

X-Frame-Options:

Dieser Header bietet eine Maßnahme, einen Service vor Clickjacking zu schützen, indem definiert wird, welche Webseiten die eigene Webseite in Frames darstellen darf.

X-XSS-Protection:

Zusätzlichen Schutz vor Cross-Site Scripting (XSS)-Angriffen bietet der X-XSS-Protection Header, indem Client Browser, die die Funktion unterstützen, versuchen, bösartige Skripte unschädlich zu machen.

X-Content-Type-Options:

Um möglichen Schwachstellen, die daraus resultieren, wenn ein Browser den Inhalt einer Seite falsch interpretiert, entgegenzuwirken, kann dieser Header verwendet werden. Somit versucht der Browser nicht den Inhalt selbst zu deuten, sondern verlässt sich auf die Angaben des Servers.

Apache

Konfiguration der unterstützen SSL/TLS-Protokolle:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1

Konfiguration der unterstützen Cipher Suites:

SSLCipherSUite "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"

Konfiguration der Header:

Header add Strict-Transport-Security "max-age=15780000"
Header always append X-Frame-Options SAMEORIGIN
Header set X-XSS-Protection "1; mode=block"
Header set X-Content-Type-Options nosniff

NGINX

Konfiguration der unterstützen SSL/TLS-Protokolle:

ssl_protocols TLSv1.2 TLSv1.1;

Konfiguration der unterstützen Cipher Suites:

ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;

Konfiguration der Header:

add_header Strict-Transport-Security: "max-age=15780000; includeSubDomains";
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;

IIS

Für die IIS-Konfiguration kann entweder die Windows Registry bearbeitet werden oder das Programm IIS Crypto (https://www.nartac.com/Products/IISCrypto/) verwendet werden.

Konfiguration der unterstützen SSL/TLS-Protokolle und der unterstützen Cipher Suites:

Konfiguration der Header:
Über den IIS Manager können für Seiten eigene Antwortheader hinzugefügt werden, dazu wählt man die gewünschte Seite aus, in diesem Fall Securai-Lab, und öffnet die „HTTP Response Headers“-Funktion.

Jetzt können über das Kontextmenü oder über das Aktionsmenü neue Antwortheader hinzugefügt werden.

Schlussendlich werden die betreffenden Header (1) und deren Werte (2) definiert.

HSTS:

Name: Strict-Transport-Security

Wert: max-age=15780000; includeSubDomains

X-Frame-Options:

Name: X-Frame-Options

Wert: SAMEORIGIN

X-XSS-Protection:

Name: X-XSS-Protection

Wert: 1; mode=block

X-Content-Type-Options:

Name: X-Content-Type-Options

Wert: nosniff

Nützliches:

Let’s Encrypt erlaubt das kostenfreie Erstellen von gültigen HTTPS Zertifikaten: https://letsencrypt.org

Qualys SSL Labs scannt einen im Internet erreichbaren Webserver und bewertet die bestehende SSL-/TLS-Konfiguration: https://www.ssllabs.com

SSLScan bietet ein Tool, um SSL-/TLS-Konfigurationen zu prüfen, die auch nicht öffentlich verfügbar sind: https://github.com/rbsec/sslscan

CanIUse erlaubt die Überprüfung, für welche Clientsysteme bestimmte Funktionen verfügbar sind: https://caniuse.com/