Was Transport Layer Security (TLS) ist und wie man es richtig benutzt.
Verschlüsselte Verbindungen sind für die Nutzung des Internets oder anderen Netzwerken nicht mehr wegzudenken. Ohne sie wäre keine sichere und vertrauliche Kommunikation über das Internet möglich. Daten könnten von Angreifern abgehört und missbraucht werden. Man stelle sich vor, man wollte auf einer ungesicherten Webseite einen Einkauf tätigen. Hierfür müssen viele persönliche Daten übermittelt werden. Das sind nicht nur der Name des Käufers und die Produkte. Auch die Adresse, Bankverbindungen, E-Mail Adressen, oder ggf. auch Passwörter. Werden diese Daten im Klartext übertragen, so könnten sie von jedem im Netzwerk, mit entsprechenden Berechtigungen, gelesen werden. Wenn man bedenkt, dass eine Internetverbindung eben nicht die Daten von dem User direkt an das Einkaufsportal bei dem er gerade bestellt schickt, sondern viele Knotenpunkte im Internet dazwischen liegen, dann ist es klar, dass diese Daten gesichert werden müssen. Nicht nur könnte ein Geheimdienst potentiell jeden Netzverkehr an einem Internetknotenpunkt abhören und mitschneiden, Angreifer könnten auch gezielt Infrastruktur angreifen um Traffic zu ihnen umzuleiten. Solche Angreifer können unter anderem Techniken wie ARP Spoofing, DNS Chache Poisoning, DNS Hijacking, WPAD Spoofing, oder BGP Route Hijacking dafür benutzen.
Um sichere Verbindungen zu ermöglichen müssen drei Eigenschaften erfüllt sein:
1. Vertraulichkeit: Nur Sender und Empfänger können Nachrichten lesen.
2. Authentizität: Sender (und Empfänger) müssen verifizieren können, mit wem sie reden.
3. Integrität: Eine Veränderung der Nachrichten während der Zustellung ist nicht möglich.
Diese drei Eigenschaften können durch kryptografische Algorithmen erreicht werden und zwar:
1. Vertraulichkeit durch starke Verschlüsselung
2. Authentizität durch die Verwendung von digitalen Zertifikaten und einer Public Key Infrastruktur (PKI)
3. Integrität durch Hashfunktionen und Message Authentication Codes (MACs)
Damit alle Teilnehmer in einem Netz dieselben Methoden benutzen können um sicher zu kommunizieren, müssen sich alle auf denselben Standard einigen. Dieser Standard heißt Transport Layer Security (TLS), oder vormals SSL.
Was ist eigentlich TLS
Transport Layer Security (TLS) ist ein Standard zur sicheren gemeinsamen Kommunikation von Netzwerkteilnehmern. Im OSI Modell operiert er auf dem Layer 5, also dem Session Layer. Das bedeutet, dass TLS zwischen der TCP Verbindung und der Representation der Applikationsdaten agiert und hat dadurch den Vorteil, dass Anwendungen nicht explizit für die Verwendung von TLS angepasst werden müssen.
Wie funktioniert TLS
TLS ist ein Protokoll mit zwei Schichten. Die erste Schicht beschreibt den generellen Aufbau eines TLS Pakets. Dazu gehören unter anderem Informationen über die verwendete Protokoll Version, Typ der Nachricht, gesetzte Optionen und Konfigurationen, sowie einer Payload. Diese Schicht ist das TLS Record Protocol. In der zweiten Schicht sind die verschiedenen Typen von TLS Records spezifiziert, die über das TLS Record Protocol ausgetauscht werden. Es gibt vier Arten von TLS Protocols:
1. TLS Handshake Protocol: Dieses Protocol wird genutzt, um eine TLS Verbindung zwischen zwei Endpunkten herzustellen. Der Handshake besteht aus mehreren Nachrichten die ausgetauscht werden. Hierbei einigen sich Client und Server auf kryptografische Algorithmen, tauschen Schlüssel aus und validieren Server und ggf. Client Zertifikate. Am Ende des Handshakes haben sich beide Parteien auf eine Menge von Algorithmen sowie einen Sitzungsschlüssel geeinigt.
2. TLS Change Cipher Spec Protocol: Um der Gegenseite mitzuteilen, dass von nun an eine verschlüsselte Verbindung genutzt werden soll, wird dieses Protokoll benutzt.
3. TLS Alert Protocol: Dieses Protokoll wird benutzt, wenn während einer Sitzung Fehler bei der Ausführung von TLS Routinen auftreten. Das können zum Beispiel Zertifikatsfehler sein, beispielsweise wenn ein Serverzertifikat abgelaufen ist.
4. TLS Application Data Protocol: Hierbei werden unter den im Handshake ausgehandelten Optionen die eigentlichen Applikationsdaten (verschlüsselt) übertragen.
Was in der Praxis zu beachten ist
So viel zur theoretischen Grundlage von TLS. In der Praxis sind jedoch ein paar mehr Details zu beachten, damit die Kommunikation auch wirklich abgesichert ist. Hierbei sind im Grunde zwei Faktoren zu beachten: Die Stärke der eingesetzten Schlüssel und Zertifikate, sowie der TLS Konfiguration in dem eingesetzten Dienst (zum Beispiel einem Webserver).
Sicherheit der Schlüssel
Der essentielle Faktor für sichere, kryptografische Algorithmen ist die Verwendung von starken, kryptografischen Schlüsseln. Der private oder auch geheime Teil eines Schlüssels wird dabei immer, wie der Name schon sagt, geheim und vertraulich gehalten werden. Fällt der private Schlüssel in die Hände eines Angreifers, so kann sich dieser als sein Opfer ausgeben, ohne dass dies jemand per se erkennen kann. Dabei ist es unerheblich, ob der Schlüssel von einem Server entwendet wird, erraten wird oder auf eine andere Art und Weise berechnet wird. Die privaten Schlüssel müssen daher auf jeden Fall gesondert gesichert werden.
Die Sicherheit von kryptografischen Primitiven wird in Bit gemessen. Hierbei bezeichnet dies im Kontext von Verschlüsselungsalgorithmen die Länge des Schlüssels. Richtwerte für die Schlüssellänge können bei der NIST, ENISA, oder der IETF eingesehen werden.
Für die Benutzung von TLS gibt es aktuell zwei Arten von Schlüsseln: RSA und ECDSA. RSA ist der Ältere von beiden Algorithmen und sehr weit verbreitet. Für eine sichere Verwendung sollten hier Schlüssel mit einer Länge von mindestens 2048 Bit genutzt werden. Das entspricht einem Sicherheitsfaktor von 112 Bit bei symmetrischer Verschlüsselung mittels AES.
Dem gegenüber steht ECDSA (Elliptic Curve Digital Signature Algorithm), für den aktuell 256 Bit Keys empfohlen werden. Dies liefert eine vergleichbare Sicherheit von 128 Bit bei AES. ECDSA Schlüssel sind weniger verbreitet als RSA Schlüssel, da diese im Vergleich zu RSA und TLS relativ neu sind. Sie haben den Vorteil, dass die verwendeten Schlüssel kürzer sind und die Berechnungen dadurch entsprechend effizienter sind.
Ein Zertifikat kann jedoch nur für einen Typ Schlüssel ausgestellt werden, daher müsste man um beide Schlüsselarten zu unterstützen auch zwei Zertifikate bereit stellen.
Zertifikate sind ein weiterer Baustein für sichere Kommunikation mittels TLS. Diese werden zur Authentifikation benutzt. Ein kryptografisches Zertifikat enthält den zu einem privaten Schlüssel korrespondierenden öffentlichen Schlüssel, weitere Informationen, sowie digitale Signaturen dieser Daten. Signaturen sind in diesem Kontext so etwas wie Beglaubigungen. Nachdem eine Signatur erstellt wurde kann mit dem entsprechenden öffentlichen Schlüssel eine Nachricht, oder ein Zertifikat selbst verifiziert werden. Wird das Zertifikat, oder eine Nachricht hinterher geändert, dann schlägt die Verifikation fehl.
Wenn beispielsweise für einen Webserver ein Zertifikat erstellt werden soll, dann wird zunächst ein sogenannter Certificate Signing Request (CSR) erstellt. Das ist eine Signatur der gewünschten Zertifikatsdaten, zum Beispiel einer Domain, zusammen mit dem Public Key der für diese Signatur benutzt wurde. Dieser CSR wird an eine Certificate Authority (CA) geschickt. Diese prüft und validiert die Daten und signiert diese dann wieder digital mit dem privaten Schlüssel ihres so genannten Root bzw. Intermediate Zertifikats. Das Ergebnis ist ein Zertifikat, welches wir auf einem Webserver benutzen können. Bei der Prüfung des Zertifikats können wir nun überprüfen, ob der Server auch den korrekten privaten Schlüssel besitzt und die Validierung mit dem öffentlichen Schlüssel der CA bestätigt uns, dass der Server auch wirklich diese Domain benutzen darf, weil er das Zertifikat sonst nicht ausgestellt hätte.
Für eine sichere Anwendung von TLS sind für die Zertifikate noch weitere Herangehensweisen zu empfehlen. Und zwar sollte jede Subdomain durch ein Zertifikat abgesichert sein, darunter fällt auch die oft übersehende Subdomain www.. Des weiteren sollte darauf geachtet werden, dass es nicht zu Zertifikatsfehlern kommt, weil beispielsweise ein Zertifikat abgelaufen ist oder eine (Sub-)domain nicht im Zertifikat eingetragen ist. Es ist von Vorteil, wenn der Erneuerungsprozess für Zertifikate automatisiert werden kann. Dadurch lässt sich die Laufzeit eines Zertifikates verringern, welches zu einem besseren Schutz führt, sollte ein Angreifer Schlüssel stehlen können. Um den Blastradius zu minimieren, wenn ein Zertifikat oder Schlüssel kompromittiert wurde, sollte dasselbe Paar aus Zertifikat und Schlüssel für unterschiedliche Services genutzt werden. Es gibt auch die Möglichkeit Zertifikate für Wildcard Domains zu erstellen. Das sollte jedoch nur mit Vorsicht genutzt werden und wenn es unbedingt nötig ist. Weitere Mechanismen, die genutzt werden können, sind Certificate Authority Authentication (CAA) und Certficate Transparency (CT) Monitoring. Bei CAA wird in einem DNS Eintrag hinterlegt, welche CA ein Zertifikat für die Domain ausstellen darf. Certificate Authorities loggen ausgestellte Zertifikate und speichern sie in Listen. Google hält unter anderem solche Listen für mehrere CAs vor, welche benutzt werden können, um zu überprüfen, ob für die eigene Domain Zertifikate von fremden Akteuren erstellt wurden. So lässt sich beispielsweise frühzeitig ein Angriff erkennen.
Sicherheit der TLS Konfiguration
Eine moderne Konfiguration zahlt sich hier aus. Einer der grundlegendsten Parameter ist die TLS Version. Empfohlen werden aktuell die Versionen TLS 1.2 und 1.3. Ältere Versionen wie TLS 1.0 oder 1.1, sowie SSL2.0 und SSL3.0 sollten nicht mehr benutzt werden.
TLS 1.3 ist die aktuellste Version und ist von sich aus als sicher entwickelt worden und brauch nicht weiter hinsichtlich bestimmter Algorithmen angepasst werden. Da jedoch auch die Version 1.2. noch weit verbreitet ist, müssen hier einige Parameter beachtet werden.
Für den Schlüsselaustausch im Handshake sollten nur Algorithmen benutzt werden, die Forward Secrecy bieten. Das bedeutet, dass ältere Sitzungsschlüssel auch aus kompromittierten Langzeitschlüsseln nicht hergeleitet werden können. Um diese Eigenschaft nutzen zu können müssen die ephemeral Versionen des Diffie-Hellman Algorithmus’ benutzt werden. Diese werden durch die Abkürzungen DHE und ECDHE gekennzeichnet.
Des weiteren sollten nur Ciphersuiten benutzt werden, die aktuell als sicher gelten. Dies sollte regelmäßig geprüft werden und die Listen sollten angepasst werden. Der Server sollte auch so eingestellt werden, dass die Reihenfolge vom Server vorgegeben wird. So werden sichere Algorithmen bevorzugt benutzt.
Es bietet sich an HTTP Scrict Transport Security (HSTS) zu benutzen. Hier erkennt der Browser automatisch, dass für eine Seite schon mal eine sichere Verbindung über TLS benutzt wurde, und es wird sichergestellt, dass die Seite wieder mittels TLS abgerufen wird.
Wenn sensible Daten transportiert werden, dann sollten diese nicht zusätzlich komprimiert, oder gecached werden. Es gibt bereits Angriffe, welche die Kompression oder den Cache ausnutzen, um Rückschlüsse auf die sensiblen Daten zu erhalten. Darüber hinaus können Content Security Policies (CSPs) benutzt werden, um potentzielle Angriffe frühzeitig erkennen und abwehren zu können.
Bei all diesen Hinweisen auf Konfigurationsoptionen muss jedoch gesagt werden, dass diese auch einen Einfluss auf die Performance haben. Hier muss individuell zwischen Performance und Sicherheit abgewogen werden.
Einige weiterführende Links
Abschließend noch ein paar Verweise auf Seiten, um gute Beispielkonfigurationen zu erhalten oder die eigene Seite auf Sicherheitsmängel prüfen zu können.
* TLS Konfigurations Generator von Mozilla
* SSLlabs TLS Testsuite von Qualis
* Validation Tool for Websites and Mail Servers
* Validation Seite für mehrere Protokolle