Kapitel 4. Transport Layer Security (TLS)

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Das SSL-Protokoll wurde ursprünglich von Netscape entwickelt, um die Sicherheit von E-Commerce-Transaktionen im Internet zu gewährleisten, die eine Verschlüsselung zum Schutz der persönlichen Daten der Kunden sowie Authentifizierungs- und Integritätsgarantien zur Gewährleistung einer sicheren Transaktion erforderten. Um dies zu erreichen, wurde das SSL-Protokoll auf der Anwendungsschicht direkt auf TCP implementiert(Abb. 4-1), so dass darüber liegende Protokolle (HTTP, E-Mail, Instant Messaging und viele andere) unverändert funktionieren und die Kommunikation über das Netzwerk sicher ist.

Wenn SSL korrekt verwendet wird, kann ein Dritter nur die Endpunkte der Verbindung, die Art der Verschlüsselung sowie die Häufigkeit und ungefähre Menge der gesendeten Daten ableiten, aber keine der tatsächlichen Daten lesen oder verändern.

Abbildung 4-1. Transport Layer Security (TLS)
Hinweis

Als das SSL-Protokoll von der IETF standardisiert wurde, wurde es in Transport Layer Security (TLS) umbenannt. Viele verwenden die Namen TLS und SSL synonym, aber technisch gesehen sind sie unterschiedlich, da sie jeweils eine andere Version des Protokolls beschreiben.

SSL 2.0 war die erste öffentlich freigegebene Version des Protokolls, wurde aber aufgrund einer Reihe von entdeckten Sicherheitslücken schnell durch SSL 3.0 ersetzt. Da das SSL-Protokoll Eigentum von Netscape war, setzte sich die IETF dafür ein, das Protokoll zu standardisieren. Das Ergebnis war RFC 2246, das im Januar 1999 veröffentlicht wurde und als TLS 1.0 bekannt wurde. Seitdem hat die IETF das Protokoll immer wieder überarbeitet, um Sicherheitsmängel zu beheben und seine Möglichkeiten zu erweitern: TLS 1.1 (RFC 4346) wurde im April 2006 veröffentlicht, TLS 1.2 (RFC 5246) im August 2008, und derzeit wird an der Definition von TLS 1.3 gearbeitet.

Lass dich jedoch nicht von der Fülle an Versionsnummern in die Irre führen: Deine Server sollten immer die neueste stabile Version des TLS-Protokolls bevorzugen und aushandeln, um die besten Garantien für Sicherheit, Leistungsfähigkeit und Leistung zu gewährleisten. Einige leistungskritische Funktionen wie HTTP/2 erfordern sogar ausdrücklich die Verwendung von TLS 1.2 oder höher und führen andernfalls zum Abbruch der Verbindung. Gute Sicherheit und Leistung gehen Hand in Hand.

Hinweis

TLS wurde entwickelt, um auf einem zuverlässigen Transportprotokoll wie TCP zu funktionieren. Es wurde jedoch auch für den Einsatz über Datagramm-Protokolle wie UDP angepasst. Das Protokoll Datagram Transport Layer Security (DTLS), das in RFC 6347 definiert ist, basiert auf dem TLS-Protokoll und bietet ähnliche Sicherheitsgarantien, ohne das Modell der Datagrammübertragung zu verändern.

Verschlüsselung, Authentifizierung und Integrität

Das TLS-Protokoll ist so konzipiert, dass es allen darüber laufenden Anwendungen drei wesentliche Dienste zur Verfügung stellt: Verschlüsselung, Authentifizierung und Datenintegrität. Technisch gesehen bist du nicht verpflichtet, alle drei Dienste in jeder Situation zu nutzen. Du kannst ein Zertifikat akzeptieren, ohne seine Echtheit zu überprüfen, aber du solltest dir über die Sicherheitsrisiken und die Auswirkungen eines solchen Vorgehens im Klaren sein. In der Praxis wird eine sichere Webanwendung alle drei Dienste nutzen.

Verschlüsselung

Ein Mechanismus um zu verschleiern, was von einem Host zu einem anderen gesendet wird.

Authentifizierung

Ein Mechanismus , um die Gültigkeit des bereitgestellten Identifikationsmaterials zu überprüfen.

Integrität

Ein Mechanismus zur Erkennung von Nachrichtenmanipulationen und -fälschungen.

Um einen kryptografisch sicheren Datenkanal einzurichten, müssen sich die Verbindungspartner darauf einigen, welche Chiffrierverfahren verwendet werden und welche Schlüssel zur Verschlüsselung der Daten eingesetzt werden. Das TLS-Protokoll sieht für diesen Austausch eine genau definierte Handshake-Sequenz vor, die wir im Abschnitt "TLS Handshake" genauer untersuchen werden . Das Geniale an diesem Handshake und der Grund, warum TLS in der Praxis funktioniert, ist die Verwendung der Public-Key-Kryptografie (auch bekannt als asymmetrische Kryptografie), die es den Peers ermöglicht, einen gemeinsamen geheimen Schlüssel auszuhandeln, ohne dass sie sich vorher kennen müssen, und dies über einen unverschlüsselten Kanal.

Als Teil des TLS-Handshakes ermöglicht das Protokoll auch die Authentifizierung der Identität beider Partner. Wenn dieser Authentifizierungsmechanismus im Browser verwendet wird, kann der Kunde überprüfen, ob der Server derjenige ist, der er vorgibt zu sein (z. B. deine Bank) und nicht jemand, der sich nur als Ziel ausgibt, indem er seinen Namen oder seine IP-Adresse fälscht. Diese Überprüfung basiert auf der etablierten Vertrauenskette - siehe "Vertrauenskette und Zertifizierungsstellen". Darüber hinaus kann der Server optional auch die Identität des Kunden überprüfen - z. B. kann ein Proxy-Server eines Unternehmens alle Mitarbeiter authentifizieren, von denen jeder sein eigenes, vom Unternehmen signiertes Zertifikat hat.

Nach der Verschlüsselung und Authentifizierung bietet das TLS-Protokoll auch einen eigenen Mechanismus zur Rahmung von Nachrichten und signiert jede Nachricht mit einem Message Authentication Code (MAC). Der MAC-Algorithmus ist eine kryptografische Einweg-Hash-Funktion (quasi eine Prüfsumme), deren Schlüssel von den beiden Verbindungspartnern ausgehandelt wird. Jedes Mal, wenn ein TLS-Datensatz gesendet wird, wird ein MAC-Wert generiert und an die Nachricht angehängt. Der Empfänger ist dann in der Lage, den gesendeten MAC-Wert zu berechnen und zu überprüfen, um die Integrität und Authentizität der Nachricht sicherzustellen.

Alle drei Mechanismen zusammen bilden die Grundlage für eine sichere Kommunikation im Internet. Alle modernen Webbrowser unterstützen eine Vielzahl von Verschlüsselungen, sind in der Lage, sowohl den Client als auch den Server zu authentifizieren und führen für jeden Datensatz eine transparente Prüfung der Nachrichtenintegrität durch.

HTTPS Überall

Unverschlüsselte Kommunikation - über HTTP und andere Protokolle - schafft eine Vielzahl von Schwachstellen in Bezug auf Datenschutz, Sicherheit und Integrität. Ein solcher Austausch ist anfällig für Abhören, Manipulation und Identitätsmissbrauch und kann die Anmeldedaten, den Verlauf, die Identität und andere sensible Informationen der Nutzer/innen preisgeben. Unsere Anwendungen müssen sich selbst und unsere Nutzer/innen vor diesen Bedrohungen schützen, indem sie Daten über HTTPS übermitteln.

HTTPS schützt die Integrität der Website

Die Verschlüsselung verhindert, dass Eindringlinge die ausgetauschten Daten manipulieren - z. B. Inhalte umschreiben, unerwünschte und bösartige Inhalte einfügen usw.

HTTPS schützt die Privatsphäre und die Sicherheit des Nutzers

Die Verschlüsselung verhindert, dass Eindringlinge die ausgetauschten Daten abhören können. Jede ungeschützte Anfrage kann sensible Informationen über den Nutzer preisgeben, und wenn diese Daten über viele Sitzungen hinweg gesammelt werden, können sie dazu verwendet werden, die Identität des Nutzers zu de-anonymisieren und andere sensible Informationen preiszugeben. Alle Surfaktivitäten sollten, soweit es die Nutzer/innen betrifft, als privat und sensibel angesehen werden.

HTTPS ermöglicht leistungsstarke Funktionen im Web

Immer mehr neue Funktionen der Webplattformen, wie z. B. der Zugriff auf die Geolokalisierung von Nutzern, das Aufnehmen von Fotos und Videos, das Ermöglichen von Offline-App-Erlebnissen und vieles mehr, erfordern eine ausdrückliche Zustimmung der Nutzer, die wiederum HTTPS voraussetzt. Die Sicherheits- und Integritätsgarantien, die HTTPS bietet, sind entscheidende Komponenten für einen sicheren Genehmigungsprozess und den Schutz der Nutzerpräferenzen.

Außerdem haben sowohl die Internet Engineering Task Force (IETF) als auch das Internet Architecture Board (IAB) Richtlinien für Entwickler und Protokolldesigner herausgegeben, die die Einführung von HTTPS dringend empfehlen:

Mit der wachsenden Abhängigkeit vom Internet sind auch die Risiken und der Einsatz für alle, die sich darauf verlassen, gestiegen. Daher liegt es in unserer Verantwortung, sowohl als Anwendungsentwickler als auch als Nutzer, dafür zu sorgen, dass wir uns schützen, indem wir überall HTTPS aktivieren.

Hinweis

Der vom Office of Management and Budget des Weißen Hauses herausgegebeneHTTPS-Only Standard ist eine gute Quelle für zusätzliche Informationen über die Notwendigkeit von HTTPS und praktische Ratschläge für dessen Einsatz.

TLS Handshake

Bevor der Client und der Server mit dem Austausch von Anwendungsdaten über TLS beginnen können, muss der verschlüsselte Tunnel ausgehandelt werden: Der Client und der Server müssen sich auf die Version des TLS-Protokolls einigen, die Ciphersuite auswählen und gegebenenfalls Zertifikate überprüfen. Leider erfordert jeder dieser Schritte neue Paketübertragungen(Abbildung 4-2) zwischen dem Client und dem Server, was zu einer zusätzlichen Startlatenz bei allen TLS-Verbindungen führt.

Abbildung 4-2. TLS-Handshake-Protokoll
Hinweis

In Abbildung 4-2 wird die gleiche (optimistische) Verzögerung von 28 Millisekunden in einer Richtung zwischen New York und London angenommen wie in den vorherigen Beispielen für den TCP-Verbindungsaufbau (siehe Tabelle 1-1).

0 ms

TLS läuft über einen zuverlässigen Transport (TCP), was bedeutet, dass wir zuerst den TCP-Drei-Wege-Handshake abschließen müssen, was einen ganzen Roundtrip dauert.

56 ms

Wenn die TCP-Verbindung hergestellt ist, sendet der Client eine Reihe von Angaben im Klartext, z. B. die Version des TLS-Protokolls, die er verwendet, die Liste der unterstützten Ciphersuites und andere TLS-Optionen, die er verwenden möchte.

84 ms

Der Server wählt die TLS-Protokollversion für die weitere Kommunikation aus, entscheidet sich für eine Ciphersuite aus der vom Kunden bereitgestellten Liste, fügt sein Zertifikat an und sendet die Antwort zurück an den Kunden. Optional kann der Server auch eine Anfrage für das Zertifikat des Kunden und Parameter für andere TLS-Erweiterungen senden.

112 ms

Wenn sich beide Seiten auf eine gemeinsame Version und Chiffre einigen können und der Client mit dem vom Server bereitgestellten Zertifikat zufrieden ist, initiiert der Client entweder den RSA- oder den Diffie-Hellman-Schlüsselaustausch, mit dem der symmetrische Schlüssel für die folgende Sitzung festgelegt wird.

140 ms

Der Server verarbeitet die vom Kunden gesendeten Schlüsselaustauschparameter, prüft die Integrität der Nachricht, indem er den MAC verifiziert, und sendet eine verschlüsselte Finished Nachricht an den Kunden zurück.

168 ms

Der Client entschlüsselt die Nachricht mit dem ausgehandelten symmetrischen Schlüssel, verifiziert die MAC und wenn alles in Ordnung ist, wird der Tunnel aufgebaut und die Anwendungsdaten können nun gesendet werden.

Wie der obige Austausch zeigt, benötigen neue TLS-Verbindungen zwei Roundtrips für einen "vollständigen Handshake" - das ist die schlechte Nachricht. In der Praxis können optimierte Implementierungen jedoch viel besser abschneiden und einen konsistenten 1-RTT TLS-Handshake liefern:

  • False Start ist eine TLS-Protokollerweiterung, die es dem Client und dem Server ermöglicht, mit der Übertragung von verschlüsselten Anwendungsdaten zu beginnen, wenn der Handshake nur teilweise abgeschlossen ist - d.h. sobald die Nachrichten ChangeCipherSpec und Finished gesendet wurden, aber ohne darauf zu warten, dass die andere Seite dasselbe tut. Diese Optimierung reduziert den Handshake-Overhead für neue TLS-Verbindungen auf einen Roundtrip; siehe "TLS False Start aktivieren".

  • Wenn der Client bereits zuvor mit dem Server kommuniziert hat, kann ein "abgekürztes Handshake" verwendet werden, das einen Roundtrip erfordert und es dem Client und dem Server außerdem ermöglicht, den CPU-Overhead zu reduzieren, indem die zuvor ausgehandelten Parameter für die sichere Sitzung wiederverwendet werden; siehe "TLS Session Resumption".

Die Kombination der beiden oben genannten Optimierungen ermöglicht einen konsistenten 1-RTT TLS Handshake für neue und wiederkehrende Besucher und spart Rechenzeit für Sitzungen, die auf der Grundlage der zuvor ausgehandelten Sitzungsparameter wieder aufgenommen werden können. Achte darauf, diese Optimierungen in deinem Einsatz zu nutzen.

Hinweis

Eines der Entwicklungsziele von TLS 1.3 ist es, die Latenzzeit für den Aufbau der sicheren Verbindung zu verringern: 1-RTT für neue und 0-RTT für wiederaufgenommene Sitzungen!

RSA, Diffie-Hellman und Forward Secrecy

Aus einer Reihe historischer und kommerzieller Gründe ist der RSA-Handshake der vorherrschende Schlüsselaustauschmechanismus in den meisten TLS-Implementierungen: Der Client erzeugt einen symmetrischen Schlüssel, verschlüsselt ihn mit dem öffentlichen Schlüssel des Servers und sendet ihn an den Server, der ihn als symmetrischen Schlüssel für die aufgebaute Sitzung verwendet. Der Server wiederum verwendet seinen privaten Schlüssel, um den gesendeten symmetrischen Schlüssel zu entschlüsseln und der Schlüsselaustausch ist abgeschlossen. Von diesem Zeitpunkt an verwenden Client und Server den ausgehandelten symmetrischen Schlüssel, um ihre Sitzung zu verschlüsseln.

Der RSA-Handshake funktioniert, hat aber eine entscheidende Schwachstelle: Dasselbe öffentlich-private Schlüsselpaar wird sowohl zur Authentifizierung des Servers als auch zur Verschlüsselung des symmetrischen Sitzungsschlüssels verwendet, der an den Server gesendet wird. Wenn sich ein Angreifer Zugang zum privaten Schlüssel des Servers verschafft und den Austausch abhört, kann er die gesamte Sitzung entschlüsseln. Schlimmer noch: Selbst wenn ein Angreifer derzeit keinen Zugriff auf den privaten Schlüssel hat, kann er die verschlüsselte Sitzung aufzeichnen und zu einem späteren Zeitpunkt entschlüsseln, sobald er den privaten Schlüssel erhalten hat.

Im Gegensatz dazu ermöglicht der Diffie-Hellman-Schlüsselaustausch dem Client und dem Server, ein gemeinsames Geheimnis auszuhandeln, ohne es explizit im Handshake mitzuteilen: Der private Schlüssel des Servers wird verwendet, um den Handshake zu signieren und zu verifizieren, aber der festgelegte symmetrische Schlüssel verlässt weder den Client noch den Server und kann von einem passiven Angreifer nicht abgefangen werden, selbst wenn dieser Zugang zum privaten Schlüssel hat.

Hinweis

Wer neugierig ist, kann sich im Wikipedia-Artikel über den Diffie-Hellman-Schlüsselaustausch über den Algorithmus und seine Eigenschaften informieren.

Das Beste ist, dass der Diffie-Hellman-Schlüsselaustausch genutzt werden kann, um das Risiko einer Kompromittierung vergangener Kommunikationssitzungen zu verringern: Wir können bei jedem Schlüsselaustausch einen neuen "ephemeren" symmetrischen Schlüssel erzeugen und die vorherigen Schlüssel verwerfen. Da die ephemeren Schlüssel nie übermittelt und für jede neue Sitzung aktiv neu ausgehandelt werden, könnte ein Angreifer im schlimmsten Fall den Client oder Server kompromittieren und auf die Sitzungsschlüssel der aktuellen und zukünftigen Sitzungen zugreifen. Die Kenntnis des privaten Schlüssels oder des aktuellen ephemeren Schlüssels hilft dem Angreifer jedoch nicht, eine der vorherigen Sitzungen zu entschlüsseln!

Die Kombination aus Diffie-Hellman-Schlüsselaustausch und ephemeren Sitzungsschlüsseln ermöglicht ein "perfektes Vorwärtsgeheimnis" (Perfect Forward Secrecy, PFS): Die Kompromittierung langfristiger Schlüssel (z. B. des privaten Schlüssels des Servers) kompromittiert nicht die vergangenen Sitzungsschlüssel und ermöglicht es dem Angreifer nicht, zuvor aufgezeichnete Sitzungen zu entschlüsseln. Eine höchst wünschenswerte Eigenschaft, um es vorsichtig auszudrücken!

Das Ergebnis ist, dass der RSA-Handshake jetzt aktiv abgeschafft wird: Alle gängigen Browser bevorzugen Chiffren, die eine Vorwärtsverschlüsselung ermöglichen (d.h. auf Diffie-Hellman-Schlüsselaustausch beruhen) und als zusätzlichen Anreiz bestimmte Protokolloptimierungen nur dann zulassen, wenn die Vorwärtsverschlüsselung verfügbar ist - z.B. 1-RTT-Handshakes über TLS False Start.

Das bedeutet, dass du in der Dokumentation deines Servers nachlesen solltest, wie du die Vorwärtsverschlüsselung aktivierst und einsetzt! Noch einmal: Gute Sicherheit und Leistung gehen Hand in Hand.

Application Layer Protocol Negotiation (ALPN)

Es kann vorkommen, dass zwei Peers ein eigenes Anwendungsprotokoll verwenden möchten, um miteinander zu kommunizieren. Eine Möglichkeit, dieses Problem zu lösen, besteht darin, das Protokoll im Voraus festzulegen, ihm einen bekannten Port zuzuweisen (z. B. Port 80 für HTTP, Port 443 für TLS) und alle Clients und Server so zu konfigurieren, dass sie diesen verwenden. In der Praxis ist dies jedoch ein langwieriger und unpraktischer Prozess: Jede Portzuweisung muss genehmigt werden und, was noch schlimmer ist, Firewalls und andere Vermittler lassen den Verkehr oft nur über die Ports 80 und 443 zu.

Um den Einsatz benutzerdefinierter Protokolle zu ermöglichen, müssen wir daher die Ports 80 oder 443 wiederverwenden und einen zusätzlichen Mechanismus zur Aushandlung des Anwendungsprotokolls verwenden. Port 80 ist für HTTP reserviert, und die HTTP-Spezifikation bietet einen speziellen Upgrade Flow für genau diesen Zweck. Die Verwendung von Upgrade kann jedoch eine zusätzliche Latenzzeit im Netzwerk verursachen und ist in der Praxis oft unzuverlässig, wenn viele Vermittler vorhanden sind; siehe "Proxies, Vermittler, TLS und neue Protokolle im Web".

Hinweis

Ein praktisches Beispiel für den HTTP-Upgrade-Workflow findest du im Abschnitt "Upgrade auf HTTP/2".

Die Lösung ist, du hast es erraten, die Verwendung von Port 443, der für sichere HTTPS-Sitzungen über TLS reserviert ist. Die Verwendung eines Ende-zu-Ende-verschlüsselten Tunnels verschleiert die Daten vor zwischengeschalteten Proxys und ermöglicht eine schnelle und zuverlässige Bereitstellung neuer Anwendungsprotokolle. Wir brauchen jedoch noch einen weiteren Mechanismus, um das Protokoll auszuhandeln, das innerhalb der TLS-Sitzung verwendet wird.

Application Layer Protocol Negotiation (ALPN) ist, wie der Name schon sagt, eine TLS-Erweiterung, die diesen Bedarf deckt. Sie erweitert den TLS-Handshake(Abbildung 4-2) und ermöglicht es den Peers, Protokolle ohne zusätzliche Roundtrips auszuhandeln. Im Einzelnen läuft der Prozess wie folgt ab:

  • Der Client fügt ein neues Feld ProtocolNameList mit der Liste der unterstützten Anwendungsprotokolle in die ClientHello Nachricht ein.

  • Der Server prüft das Feld ProtocolNameList und gibt ein Feld ProtocolName zurück, das das gewählte Protokoll als Teil der Nachricht ServerHello angibt.

Der Server kann nur mit einem einzigen Protokollnamen antworten, und wenn er keines der vom Kunden gewünschten Protokolle unterstützt, kann er die Verbindung abbrechen. Sobald der TLS-Handshake abgeschlossen ist, der sichere Tunnel aufgebaut ist und sich Client und Server einig sind, welches Anwendungsprotokoll verwendet werden soll, können Client und Server sofort mit dem Austausch von Nachrichten über das ausgehandelte Protokoll beginnen.

Server Name Indication (SNI)

Ein verschlüsselter TLS-Tunnel kann zwischen zwei beliebigen TCP-Peers aufgebaut werden: Der Client muss nur die IP-Adresse des anderen Peers kennen, um die Verbindung herzustellen und den TLS-Handshake durchzuführen. Aber was ist, wenn der Server mehrere unabhängige Websites mit jeweils eigenem TLS-Zertifikat unter derselben IP-Adresse hosten will - wie funktioniert das? Fangfrage: Es funktioniert nicht.

Um dieses Problem zu lösen, wurde die Server Name Indication (SNI)-Erweiterung in das TLS-Protokoll aufgenommen, die es dem Client ermöglicht, den Hostnamen, mit dem er sich verbinden will, als Teil des TLS-Handshakes anzugeben. Der Server wiederum ist in der Lage, den in der Nachricht ClientHello gesendeten SNI-Hostnamen zu überprüfen, das entsprechende Zertifikat auszuwählen und den TLS-Handshake für den gewünschten Host abzuschließen.

TLS Session Resumption

Die zusätzliche Latenzzeit und die Rechenkosten für den vollständigen TLS-Handshake bedeuten für alle Anwendungen, die eine sichere Kommunikation benötigen, einen erheblichen Leistungsverlust. Um einen Teil der Kosten zu mindern, bietet TLS einen Mechanismus, um dieselben ausgehandelten geheimen Schlüsseldaten zwischen mehreren Verbindungen wieder aufzunehmen oder zu teilen.

Session Identifier

Der erste Mechanismus zur Wiederaufnahme von Sitzungskennungen (RFC 5246) wurde in SSL 2.0 eingeführt, der es dem Server ermöglichte, eine 32-Byte-Sitzungskennung zu erstellen und als Teil seiner ServerHello -Nachricht während der vollständigen TLS-Aushandlung zu senden, die wir bereits gesehen haben. Mit der Sitzungskennung können sowohl der Client als auch der Server die zuvor ausgehandelten Sitzungsparameter - verschlüsselt durch die Sitzungskennung - speichern und für eine spätere Sitzung wiederverwenden.

Der Client kann die Sitzungs-ID in die ClientHello Nachricht einfügen, um dem Server mitzuteilen, dass er sich noch an die ausgehandelte Cipher Suite und die Schlüssel aus dem vorherigen Handshake erinnert und in der Lage ist, sie wieder zu verwenden. Wenn der Server in der Lage ist, die Sitzungsparameter, die mit der angegebenen ID verbunden sind, in seinem Cache zu finden, kann ein verkürzter Handshake(Abbildung 4-3) stattfinden. Andernfalls ist eine vollständige neue Sitzungsaushandlung erforderlich, bei der eine neue Sitzungs-ID erzeugt wird.

Abbildung 4-3. Abgekürztes TLS-Handshake-Protokoll

Durch die Nutzung von Sitzungskennungen entfällt ein kompletter Roundtrip sowie der Overhead der Public-Key-Kryptografie, die zur Aushandlung des gemeinsamen geheimen Schlüssels verwendet wird. So kann eine sichere Verbindung schnell und ohne Sicherheitsverlust aufgebaut werden, da wir die zuvor ausgehandelten Sitzungsdaten wiederverwenden.

Hinweis

Die Sitzungswiederaufnahme ist eine wichtige Optimierung sowohl für HTTP/1.x- als auch für HTTP/2-Einsätze. Durch den verkürzten Handshake entfällt ein ganzer Roundtrip an Latenz und die Rechenkosten für beide Seiten werden erheblich reduziert.

Wenn der Browser mehrere Verbindungen zum selben Host benötigt (z. B. wenn HTTP/1.x verwendet wird), wartet er oft absichtlich, bis die erste TLS-Verhandlung abgeschlossen ist, bevor er weitere Verbindungen zum selben Server öffnet, damit diese "fortgesetzt" werden können und dieselben Sitzungsparameter wieder verwenden. Wenn du dir jemals eine Netzwerkaufzeichnung angesehen hast und dich gefragt hast, warum du selten mehrere TLS-Verhandlungen mit demselben Host siehst, dann ist das der Grund dafür!

Eine der praktischen Einschränkungen des Session Identifiers-Mechanismus besteht jedoch darin, dass der Server für jeden Client einen Sitzungs-Cache erstellen und pflegen muss. Dies führt zu mehreren Problemen auf dem Server, der jeden Tag Zehntausende oder sogar Millionen von einzelnen Verbindungen sehen kann: Er verbraucht Speicher für jede offene TLS-Verbindung, benötigt einen Sitzungskennungs-Cache und Räumungsrichtlinien und stellt eine nicht unerhebliche Herausforderung für beliebte Websites mit vielen Servern dar, die im Idealfall einen gemeinsamen TLS-Sitzungscache verwenden sollten, um die beste Leistung zu erzielen.

Keines der oben genannten Probleme ist unlösbar, und viele Websites mit hohem Datenverkehr verwenden heute erfolgreich Sitzungskennungen. Bei einem Einsatz auf mehreren Servern müssen Sitzungsidentifikatoren jedoch sorgfältig durchdacht und die Systemarchitektur entsprechend angepasst werden, um einen gut funktionierenden Sitzungscache zu gewährleisten.

Session Tickets

Um dieses Problem für den serverseitigen Einsatz von TLS-Sitzungscaches zu lösen, wurde der Ersatzmechanismus "Session Ticket" (RFC 5077) eingeführt, der den Server von der Pflicht befreit, den Sitzungsstatus pro Client zu speichern. Wenn der Client angibt, dass er Session Tickets unterstützt, kann der Server stattdessen einen New Session Ticket Datensatz einfügen, der alle ausgehandelten Sitzungsdaten enthält, die mit einem geheimen Schlüssel verschlüsselt sind, den nur der Server kennt.

Dieses Sitzungs-Ticket wird dann vom Kunden gespeichert und kann in die SessionTicket Erweiterung innerhalb der ClientHello Nachricht einer nachfolgenden Sitzung aufgenommen werden. So werden alle Sitzungsdaten nur auf dem Client gespeichert, aber das Ticket ist trotzdem sicher, weil es mit einem Schlüssel verschlüsselt wird, den nur der Server kennt.

Die Sitzungskennungen und die Sitzungstickets werden allgemein als Sitzungscaching und zustandslose Wiederaufnahme bezeichnet. Die wichtigste Verbesserung der zustandslosen Wiederaufnahme besteht darin, dass der serverseitige Sitzungscache entfällt. Dies vereinfacht die Bereitstellung, da der Client das Sitzungsticket bei jeder neuen Verbindung zum Server bereitstellen muss, d. h. bis das Ticket abgelaufen ist.

Hinweis

In der Praxis erfordert der Einsatz von Sitzungstickets auf einer Reihe von Servern mit Lastverteilung ebenfalls eine sorgfältige Planung und Systemarchitektur: Alle Server müssen mit demselben Sitzungsschlüssel initialisiert werden, und es ist ein zusätzlicher Mechanismus erforderlich, um den gemeinsamen Schlüssel regelmäßig und sicher auf allen Servern zu rotieren.

Vertrauenskette und Zertifizierungsstellen

Authentifizierung ist ein wesentlicher Bestandteil des Aufbaus jeder TLS-Verbindung. Schließlich ist es möglich, über einen verschlüsselten Tunnel mit jeder beliebigen Gegenstelle ein Gespräch zu führen, auch mit einem Angreifer. Wenn wir nicht sicher sein können, dass der Host, mit dem wir sprechen, derjenige ist, dem wir vertrauen, könnte die ganze Verschlüsselungsarbeit umsonst gewesen sein. Um zu verstehen, wie wir die Identität der Gegenstelle überprüfen können, schauen wir uns einen einfachen Authentifizierungsablauf zwischen Alice und Bob an:

  • Sowohl Alice als auch Bob erzeugen ihre eigenen öffentlichen und privaten Schlüssel.

  • Sowohl Alice als auch Bob verbergen ihre jeweiligen privaten Schlüssel.

  • Alice teilt ihren öffentlichen Schlüssel mit Bob, und Bob teilt seinen mit Alice.

  • Alice erstellt eine neue Nachricht für Bob und signiert sie mit ihrem privaten Schlüssel.

  • Bob verwendet den öffentlichen Schlüssel von Alice, um die Signatur der Nachricht zu überprüfen.

Vertrauen ist eine Schlüsselkomponente des vorangegangenen Austauschs. Bei der Verschlüsselung mit öffentlichen Schlüsseln können wir zwar den öffentlichen Schlüssel des Absenders verwenden, um zu überprüfen, ob die Nachricht mit dem richtigen privaten Schlüssel signiert wurde, aber die Entscheidung, den Absender zu akzeptieren, basiert immer noch auf Vertrauen. In dem soeben gezeigten Austausch könnten Alice und Bob ihre öffentlichen Schlüssel ausgetauscht haben, als sie sich persönlich getroffen haben. Da sie sich gut kennen, sind sie sicher, dass ihr Austausch nicht von einem Betrüger kompromittiert wurde - vielleicht haben sie sogar ihre Identität durch einen anderen, geheimen (physischen) Handschlag überprüft, den sie zuvor vereinbart hatten!

Als nächstes erhält Alice eine Nachricht von Charlie, den sie noch nie getroffen hat, der aber behauptet, ein Freund von Bob zu sein. Um zu beweisen, dass er mit Bob befreundet ist, hat Charlie Bob gebeten, seinen eigenen öffentlichen Schlüssel mit Bobs privatem Schlüssel zu signieren und diese Signatur an seine Nachricht anzuhängen(Abbildung 4-4). In diesem Fall prüft Alice zunächst Bobs Signatur von Charlies Schlüssel. Sie kennt Bobs öffentlichen Schlüssel und kann daher überprüfen, ob Bob Charlies Schlüssel tatsächlich signiert hat. Da sie Bobs Entscheidung, Charlie zu verifizieren, vertraut, nimmt sie die Nachricht an und führt eine ähnliche Integritätsprüfung an Charlies Nachricht durch, um sicherzustellen, dass sie tatsächlich von Charlie stammt.

Abbildung 4-4. Vertrauenskette für Alice, Bob und Charlie

Was wir gerade getan haben, ist eine Vertrauenskette aufzubauen: Alice vertraut Bob, Bob vertraut Charlie, und durch transitives Vertrauen beschließt Alice, Charlie zu vertrauen. Solange niemand in der Kette kompromittiert wird, können wir die Liste der vertrauenswürdigen Parteien aufbauen und erweitern.

Die Authentifizierung im Web und in deinem Browser folgt genau demselben Prozess wie dargestellt. Das bedeutet, dass du dich an dieser Stelle fragen solltest: Wem vertraut dein Browser, und wem vertraust du, wenn du den Browser benutzt? Es gibt mindestens drei Antworten auf diese Frage:

Manuell festgelegte Zertifikate

Jeder Browser und jedes Betriebssystem bietet einen Mechanismus, mit dem du jedes Zertifikat, dem du vertraust, manuell importieren kannst. Wie du das Zertifikat erhältst und seine Integrität überprüfst, ist ganz dir überlassen.

Zertifizierungsstellen

Ein Zertifikat authority (CA) ist eine vertrauenswürdige dritte Partei, der sowohl das Subjekt (Besitzer) des Zertifikats als auch die Partei, die sich auf das Zertifikat verlässt, vertrauen.

Der Browser und das Betriebssystem

Jedes Betriebssystem und die meisten Browser werden mit einer Liste bekannter Zertifizierungsstellen ausgeliefert. Du vertraust also auch darauf, dass die Anbieter dieser Software eine Liste vertrauenswürdiger Parteien bereitstellen und pflegen.

In der Praxis wäre es unpraktisch, jeden einzelnen Schlüssel für jede Website zu speichern und manuell zu überprüfen (obwohl du das kannst, wenn du willst). Daher besteht die gängigste Lösung darin, diese Aufgabe von Zertifizierungsstellen (CAs) übernehmen zu lassen(Abbildung 4-5): Der Browser gibt an, welchen CAs er vertraut (Root-CAs), und die CAs müssen dann jede von ihnen signierte Website überprüfen und sicherstellen, dass diese Zertifikate nicht missbraucht oder kompromittiert werden. Wenn die Sicherheit einer Website mit einem CA-Zertifikat verletzt wird, liegt es auch in der Verantwortung dieser CA, das gefährdete Zertifikat zu widerrufen.

Abbildung 4-5. CA-Signierung von digitalen Zertifikaten

Jeder Browser ermöglicht es dir, die Vertrauenskette deiner sicheren Verbindung zu überprüfen(Abbildung 4-6), was normalerweise durch einen Klick auf das Schloss-Symbol neben der URL möglich ist.

Abbildung 4-6. Vertrauenskette des Zertifikats für igvita.com (Google Chrome, v25)

  • Das igvita.com-Zertifikat ist von StartCom Class 1 Primary Intermediate Server signiert.

  • Das StartCom-Zertifikat für den primären Zwischenserver der Klasse 1 wird von der StartCom-Zertifizierungsstelle unterzeichnet.

  • Die StartCom Certification Authority ist eine anerkannte Stammzertifizierungsstelle.

Der "Vertrauensanker" für die gesamte Kette ist die Stammzertifizierungsstelle, die in diesem Fall die StartCom Certification Authority ist. Jeder Browser wird mit einer voreingestellten Liste vertrauenswürdiger Zertifizierungsstellen ("Roots") ausgeliefert, und in diesem Fall vertraut der Browser dem StartCom-Root-Zertifikat und kann es verifizieren. Durch eine transitive Vertrauenskette zwischen dem Browser, dem Browserhersteller und der StartCom-Zertifizierungsstelle wird das Vertrauen auf unsere Zielseite ausgeweitet.

Zertifikatssperrung

Gelegentlich muss der Aussteller eines Zertifikats das Zertifikat aus verschiedenen Gründen widerrufen oder für ungültig erklären: Der private Schlüssel des Zertifikats wurde kompromittiert, die Zertifizierungsstelle selbst wurde kompromittiert oder es gibt eine Reihe von harmloseren Gründen wie z. B. ein Ersatzzertifikat, eine Änderung der Zugehörigkeit usw. Deshalb enthalten die Zertifikate selbst Anweisungen(Abbildung 4-7), wie man überprüfen kann, ob sie widerrufen wurden. Um sicherzustellen, dass die Vertrauenskette nicht gefährdet wird, kann jeder Peer den Status jedes Zertifikats überprüfen, indem er die eingebetteten Anweisungen zusammen mit den Signaturen befolgt, während er die Zertifikatskette überprüft.

Abbildung 4-7. CRL- und OCSP-Anweisungen für igvita.com (Google Chrome, v25)

Zertifikatswiderrufsliste (CRL)

Certificate Revocation List (CRL) ist in RFC 5280 definiert und beschreibt einen einfachen Mechanismus, um den Status eines jeden Zertifikats zu überprüfen: Jede Zertifizierungsstelle führt eine Liste mit den Seriennummern der widerrufenen Zertifikate und veröffentlicht diese in regelmäßigen Abständen. Jeder, der versucht, ein Zertifikat zu überprüfen, kann die Widerrufsliste herunterladen, sie zwischenspeichern und das Vorhandensein einer bestimmten Seriennummer darin überprüfen - ist sie vorhanden, wurde das Zertifikat widerrufen.

Dieses Verfahren ist einfach und unkompliziert, hat aber eine Reihe von Einschränkungen:

  • Die wachsende Zahl der Widerrufe bedeutet, dass die CRL-Liste nur noch länger wird und jeder Kunde die gesamte Liste der Seriennummern abrufen muss.

  • Es gibt keinen Mechanismus für eine sofortige Benachrichtigung über die Sperrung eines Zertifikats - wenn die CRL vom Kunden vor der Sperrung des Zertifikats zwischengespeichert wurde, hält die CRL das gesperrte Zertifikat für gültig, bis der Cache abläuft.

  • Die Notwendigkeit, die neueste CRL-Liste von der CA abzurufen, kann die Zertifikatsüberprüfung blockieren, was den TLS-Handshake erheblich verzögern kann.

  • Der Abruf der CRL kann aus verschiedenen Gründen fehlschlagen, und in solchen Fällen ist das Verhalten des Browsers undefiniert. Die meisten Browser behandeln solche Fälle als "Soft Fail" und lassen die Überprüfung weiterlaufen - ja, pfui.

Online Certificate Status Protocol (OCSP)

Um einige der Einschränkungen des CRL-Mechanismus anzugehen, wurde mit RFC 2560 das Online Certificate Status Protocol (OCSP) eingeführt, das einen Mechanismus zur Echtzeitprüfung des Zertifikatsstatus bietet. Im Gegensatz zur CRL-Datei, die alle widerrufenen Seriennummern enthält, kann der Client mit OCSP die Zertifikatsdatenbank der CA direkt nach der fraglichen Seriennummer abfragen, während er die Zertifikatskette validiert.

Dadurch verbraucht der OCSP-Mechanismus weniger Bandbreite und ist in der Lage, eine Validierung in Echtzeit durchzuführen. Die Anforderung, OCSP-Abfragen in Echtzeit durchzuführen, bringt jedoch eine Reihe von Problemen mit sich:

  • Die CA muss in der Lage sein, die Last der Echtzeitabfragen zu bewältigen.

  • Die Zertifizierungsstelle muss sicherstellen, dass der Dienst jederzeit einsatzbereit und global verfügbar ist.

  • OCSP-Anfragen in Echtzeit können die Privatsphäre des Kunden beeinträchtigen, da die CA weiß, welche Websites der Kunde besucht.

  • Der Client muss OCSP-Anfragen blockieren, während er die Zertifikatskette validiert.

  • Das Verhalten des Browsers ist wiederum undefiniert und führt in der Regel zu einem "Soft Fail", wenn der OCSP-Abruf aufgrund einer Netzwerkzeitüberschreitung oder anderer Fehler fehlschlägt.

Hinweis

Die Firefox-Telemetrie zeigt, dass OCSP-Anfragen in bis zu 15 % der Fälle eine Zeitüberschreitung verursachen und den TLS-Handshake im Erfolgsfall um etwa 350 ms verlängern - siehe hpbn.co/ocsp-performance.

OCSP-Heftung

Aus den oben genannten Gründen bieten weder CRL- noch OSCP-Sperrmechanismen die Sicherheits- und Leistungsgarantien, die wir uns für unsere Anwendungen wünschen. Aber verzweifle nicht, denn OCSP Stapling (RFC 6066, "Certificate Status Request"-Erweiterung) löst die meisten Probleme, die wir bereits gesehen haben, indem die Validierung vom Server durchgeführt und als Teil des TLS-Handshakes an den Client gesendet ("gestapelt") werden kann:

  • Anstatt dass der Kunde die OCSP-Anfrage stellt, ist es der Server, der regelmäßig die signierte und mit einem Zeitstempel versehene OCSP-Antwort von der CA abruft.

  • Der Server fügt dann die signierte OCSP-Antwort als Teil des TLS-Handshakes an (d.h. er "klammert" sie), damit der Client sowohl das Zertifikat als auch den angehängten, von der CA signierten OCSP-Sperrvermerk überprüfen kann.

Dieser Rollentausch ist sicher, da der geklammerte Datensatz von der CA signiert wird und vom Kunden überprüft werden kann, und bietet eine Reihe wichtiger Vorteile:

  • Der Kunde gibt seinen Navigationsverlauf nicht preis.

  • Der Client muss den OCSP-Server nicht blockieren und abfragen.

  • Der Client kann die Widerrufsbearbeitung "hart scheitern" lassen, wenn der Server sich dafür entscheidet (indem er das OSCP-Flag "Must-Staple" bekannt gibt) und die Überprüfung fehlschlägt.

Kurz gesagt: Um die besten Sicherheits- und Leistungsgarantien zu erhalten, solltest du OCSP Stapling auf deinen Servern konfigurieren und testen.

TLS-Protokoll

Ähnlich wie bei und den darunter liegenden IP- oder TCP-Schichten werden alle Daten, die innerhalb einer TLS-Sitzung ausgetauscht werden, über ein genau definiertes Protokoll übertragen(Abbildung 4-8). Das TLS-Record-Protokoll ist für die Identifizierung der verschiedenen Nachrichtentypen (Handshake, Alarm oder Daten über das Feld "Content Type") sowie für die Sicherung und Überprüfung der Integrität jeder Nachricht verantwortlich.

Abbildung 4-8. TLS-Datensatzstruktur

Ein typischer Arbeitsablauf für die Bereitstellung von Anwendungsdaten sieht folgendermaßen aus:

  • Das Protokoll empfängt Anwendungsdaten.

  • Die empfangenen Daten werden in Blöcke unterteilt: maximal214 Byte oder 16 KB pro Datensatz.

  • Der Message Authentication Code (MAC) oder HMAC wird zu jedem Datensatz hinzugefügt.

  • Die Daten in jedem Datensatz werden mit der ausgehandelten Chiffre verschlüsselt.

Sobald diese Schritte abgeschlossen sind, werden die verschlüsselten Daten für den Transport an die TCP-Schicht weitergegeben. Auf der Empfängerseite läuft derselbe Arbeitsablauf in umgekehrter Reihenfolge ab: Entschlüsselung des Datensatzes mit der ausgehandelten Chiffre, Überprüfung der MAC, Extraktion und Weiterleitung der Daten an die darüber liegende Anwendung.

Die gute Nachricht ist, dass all die soeben gezeigte Arbeit von der TLS-Schicht selbst erledigt wird und für die meisten Anwendungen völlig transparent ist. Allerdings bringt das Protokoll einige wichtige Auswirkungen mit sich, die wir beachten müssen:

  • Die maximale TLS-Datensatzgröße beträgt 16 KB

  • Jeder Datensatz enthält einen 5-Byte-Header, einen MAC (bis zu 20 Byte für SSLv3, TLS 1.0, TLS 1.1 und bis zu 32 Byte für TLS 1.2) und ein Padding, wenn eine Blockverschlüsselung verwendet wird.

  • Um den Datensatz zu entschlüsseln und zu überprüfen, muss der gesamte Datensatz verfügbar sein.

Wenn du die Möglichkeit hast, die richtige Datensatzgröße für deine Anwendung zu wählen, kann dies eine wichtige Optimierung sein. Kleine Datensätze verursachen einen größeren CPU- und Byte-Overhead aufgrund des Datensatz-Rahmens und der MAC-Verifizierung, während große Datensätze von der TCP-Schicht zugestellt und wieder zusammengesetzt werden müssen, bevor sie von der TLS-Schicht verarbeitet und an deine Anwendung weitergeleitet werden können - lies weiter unter "TLS-Datensatzgröße optimieren", um alle Einzelheiten zu erfahren.

Optimieren für TLS

Der Einsatz deiner Anwendung über TLS erfordert einige zusätzliche Arbeiten, sowohl innerhalb deiner Anwendung (z. B. die Umstellung von Ressourcen auf HTTPS, um gemischte Inhalte zu vermeiden) als auch bei der Konfiguration der Infrastruktur, die für die Bereitstellung der Anwendungsdaten über TLS verantwortlich ist. Ein gut abgestimmter Einsatz kann einen enormen positiven Einfluss auf die beobachtete Leistung, das Nutzererlebnis und die Gesamtbetriebskosten haben. Lasst uns eintauchen.

Rechenkosten reduzieren

Der Aufbau von und die Aufrechterhaltung eines verschlüsselten Kanals verursachen zusätzliche Rechenkosten für beide Peers. Dazu gehört zunächst die asymmetrische Verschlüsselung (öffentlicher Schlüssel), die während des TLS-Handshakes verwendet wird (siehe "TLS-Handshake"). Sobald ein gemeinsames Geheimnis festgelegt ist, wird es als symmetrischer Schlüssel verwendet, um alle TLS-Datensätze zu verschlüsseln.

Wie wir bereits erwähnt haben, ist die öffentliche Schlüsselkryptografie im Vergleich zur symmetrischen Schlüsselkryptografie rechenintensiver und erforderte in den Anfängen des Internets oft zusätzliche Hardware für das "SSL-Offloading". Die gute Nachricht ist, dass dies heute nicht mehr nötig ist. Was früher spezielle Hardware erforderte, kann heute direkt auf der CPU erledigt werden. Große Unternehmen wie Facebook, Twitter und Google, die TLS für Milliarden von Nutzern anbieten, führen alle notwendigen TLS-Verhandlungen und Berechnungen in Software und auf handelsüblicher Hardware durch.

Im Januar dieses Jahres (2010) ist Google Mail dazu übergegangen, standardmäßig HTTPS für alles zu verwenden. Zuvor war es als Option eingeführt worden, aber jetzt verwenden alle unsere Nutzer/innen HTTPS, um ihre E-Mails zwischen ihren Browsern und Google zu sichern. Um dies zu erreichen, mussten wir keine zusätzlichen Maschinen und keine spezielle Hardware einsetzen. Auf unseren produktiven Frontend-Rechnern macht SSL/TLS weniger als 1 % der CPU-Last, weniger als 10 KB Speicherplatz pro Verbindung und weniger als 2 % des Netzwerk-Overheads aus. Viele Menschen glauben, dass SSL/TLS viel CPU-Zeit beansprucht, und wir hoffen, dass die vorstehenden Zahlen (die zum ersten Mal veröffentlicht werden) dazu beitragen, dies zu widerlegen.

Wenn du jetzt aufhörst zu lesen, brauchst du dich nur an eines zu erinnern: SSL/TLS ist nicht mehr rechenintensiv.

Adam Langley (Google)

Wir haben TLS in großem Maßstab sowohl mit Hardware- als auch mit Software-Lastverteilern eingesetzt. Wir haben festgestellt, dass moderne softwarebasierte TLS-Implementierungen, die auf handelsüblichen CPUs laufen, schnell genug sind, um eine hohe HTTPS-Verkehrslast zu bewältigen, ohne dass wir auf spezielle Verschlüsselungshardware zurückgreifen müssen. Wir wickeln unseren gesamten HTTPS-Verkehr mit Software ab, die auf handelsüblicher Hardware läuft.

Doug Beaver (Facebook)

Elliptic Curve Diffie-Hellman (ECDHE) ist bei gleichem Sicherheitsniveau nur wenig teurer als RSA... Im praktischen Einsatz haben wir festgestellt, dass die Aktivierung und Priorisierung von ECDHE-Chiffriersuiten die CPU-Auslastung nur unwesentlich erhöht. HTTP-Keepalives und Sitzungswiederaufnahme bedeuten, dass die meisten Anfragen keinen vollständigen Handshake erfordern, so dass die Handshake-Operationen unsere CPU-Auslastung nicht dominieren. Wir stellen fest, dass 75 % der Kundenanfragen von Twitter über Verbindungen gesendet werden, die mit ECDHE aufgebaut wurden. Die verbleibenden 25 % bestehen größtenteils aus älteren Clients, die die ECDHE-Cipher-Suites noch nicht unterstützen.

Jacob Hoffman-Andrews (Twitter)

Um die besten Ergebnisse bei deinen eigenen Einsätzen zu erzielen, solltest du das Beste aus der "TLS-Sitzungswiederaufnahme" herausholen: Setze sie ein, miss sie und optimiere ihre Erfolgsrate. Dadurch, dass die kostspieligen Verschlüsselungsoperationen des öffentlichen Schlüssels nicht mehr bei jedem Handshake durchgeführt werden müssen, werden sowohl die Rechen- als auch die Latenzkosten von TLS erheblich gesenkt; es gibt keinen Grund, CPU-Zyklen für Arbeit zu verwenden, die nicht notwendig ist.

Hinweis

Apropos Optimierung der CPU-Zyklen: Achte darauf, dass deine Server mit der neuesten Version der TLS-Bibliotheken auf dem neuesten Stand sind! Zusätzlich zu den Sicherheitsverbesserungen wirst du oft auch Leistungsvorteile feststellen. Sicherheit und Leistung gehen Hand in Hand.

Aktiviere 1-RTT TLS Handshakes

Ein nicht optimierter TLS-Einsatz kann leicht viele zusätzliche Roundtrips verursachen und zu erheblichen Latenzen für den Nutzer führen - z. B. Multi-RTT-Handshakes, langsame und ineffektive Zertifikatswiderrufsüberprüfungen, große TLS-Datensätze, die mehrere Roundtrips erfordern, und so weiter. Sei nicht so eine Seite, du kannst es viel besser.

Ein gut abgestimmter TLS-Einsatz sollte höchstens einen zusätzlichen Roundtrip für die Aushandlung der TLS-Verbindung hinzufügen, unabhängig davon, ob es sich um eine neue oder wiederaufgenommene Verbindung handelt, und alle anderen Latenzfallen vermeiden: Konfiguriere die Sitzungswiederaufnahme und aktiviere die Vorwärtsgeheimhaltung, um TLS False Start zu ermöglichen.

Hinweis

Um die beste End-to-End-Leistung zu erzielen, solltest du sowohl eigene als auch fremde Dienste und Server überprüfen, die von deiner Anwendung genutzt werden, einschließlich deines CDN-Anbieters. Einen schnellen Überblick über beliebte Server und CDNs findest du unter istlsfastyet.com.

Optimiere die Wiederverwendung von Verbindungen

Der beste Weg, um sowohl die Latenzzeit als auch den Rechenaufwand beim Aufbau neuer TCP+TLS-Verbindungen zu minimieren, ist die Optimierung der Wiederverwendung von Verbindungen. Dadurch amortisieren sich die Kosten für den Verbindungsaufbau über alle Anfragen hinweg und der Nutzer erhält ein viel schnelleres Erlebnis.

Vergewissere dich, dass deine Server- und Proxy-Konfigurationen so eingerichtet sind, dass sie Keepalive-Verbindungen zulassen, und überprüfe deine Timeout-Einstellungen für die Verbindung. Viele beliebte Server setzen aggressive Verbindungs-Timeouts (z. B. einige Apache-Versionen standardmäßig auf 5 Sekunden), die viele unnötige Neuverhandlungen erzwingen. Die besten Ergebnisse erzielst du, wenn du deine Logs und Analysen nutzt, um die optimalen Timeout-Werte zu ermitteln.

Hebelwirkung Vorzeitige Beendigung

Wie wir in Kapitel 1 besprochen haben, können wir unsere Pakete vielleicht nicht schneller, aber kürzer transportieren. Indem wir unsere "Kanten"-Server näher am Nutzer platzieren(Abbildung 4-9), können wir die Roundtrip-Zeiten und die Gesamtkosten der TCP- und TLS-Handshakes deutlich reduzieren.

Abbildung 4-9. Vorzeitige Beendigung von Client-Verbindungen

Eine einfache Möglichkeit, dies zu erreichen, besteht darin, die Dienste eines Content Delivery Network (CDN) zu nutzen, das Pools von Kanten-Servern rund um den Globus unterhält, oder einen eigenen Server einzurichten. Indem du dem/der Nutzer/in die Möglichkeit gibst, seine/ihre Verbindung mit einem nahegelegenen Server zu beenden, anstatt über Ozeane und Kontinentalverbindungen zu deinem Ursprung zu reisen, erhält der/die Kunde/in den Vorteil einer "frühen Beendigung" mit kürzeren Roundtrips. Diese Technik ist für statische und dynamische Inhalte gleichermaßen nützlich und wichtig: Statische Inhalte können im Cache gespeichert und von den Edge-Servern bereitgestellt werden, während dynamische Anfragen über bestehende Verbindungen vom Edge zum Ursprung weitergeleitet werden können.

Konfigurieren von Session Caching und zustandsloser Wiederaufnahme

Das Beenden der Verbindung näher am Nutzer ist eine Optimierung, die die Latenz für deine Nutzer in jedem Fall verringert, aber auch hier gilt: Kein Bit ist schneller als ein nicht gesendetes Bit - sende weniger Bits. Durch die Aktivierung des TLS-Sitzungscachings und der zustandslosen Wiederaufnahme der Verbindung kann ein ganzer Roundtrip an Latenzzeit vermieden und der Rechenaufwand für wiederkehrende Besucher verringert werden.

Sitzungskennungen ( ), auf denen das TLS-Sitzungscaching beruht, wurden in SSL 2.0 eingeführt und werden von den meisten Clients und Servern unterstützt. Wenn du TLS auf deinem Server konfigurierst, solltest du jedoch nicht davon ausgehen, dass die Sitzungskennung standardmäßig aktiviert ist. Tatsächlich ist sie bei den meisten Servern standardmäßig ausgeschaltet - aber du weißt es besser! Überprüfe deine Server-, Proxy- und CDN-Konfiguration noch einmal:

  • Server mit mehreren Prozessen oder Workern sollten einen gemeinsamen Sitzungscache verwenden.

  • Die Größe des gemeinsamen Sitzungscaches sollte auf deinen Datenverkehr abgestimmt werden.

  • Es sollte ein Zeitlimit für die Sitzung festgelegt werden.

  • In einer Einrichtung mit mehreren Servern ist die Weiterleitung derselben Client-IP oder derselben TLS-Sitzungs-ID an denselben Server eine Möglichkeit, den Sitzungscache gut zu nutzen.

  • Wenn ein "Sticky"-Lastausgleich nicht möglich ist, sollte ein gemeinsamer Cache zwischen verschiedenen Servern verwendet werden, um eine gute Auslastung des Sitzungscaches zu gewährleisten, und es muss ein sicherer Mechanismus eingerichtet werden, um die geheimen Schlüssel zur Entschlüsselung der bereitgestellten Sitzungstickets auszutauschen und zu aktualisieren.

  • Überprüfe und überwache deine TLS-Sitzungscache-Statistiken für eine optimale Leistung.

In der Praxis solltest du, um die besten Ergebnisse zu erzielen, sowohl Sitzungs-Caching als auch Sitzungs-Ticket-Mechanismen konfigurieren. Diese Mechanismen arbeiten zusammen, um sowohl für neue als auch für ältere Kunden die beste Abdeckung zu gewährleisten.

TLS-Fehlstart aktivieren

Die Sitzungswiederaufnahme bietet zwei wichtige Vorteile: Sie eliminiert einen zusätzlichen Handshake-Roundtrip für wiederkehrende Besucher und reduziert die Rechenkosten des Handshakes, indem sie die Wiederverwendung zuvor ausgehandelter Sitzungsparameter ermöglicht. Sie hilft jedoch nicht, wenn der Besucher zum ersten Mal mit dem Server kommuniziert oder wenn die vorherige Sitzung abgelaufen ist.

Um das Beste aus beiden Welten zu bekommen - ein Roundtrip-Handshake für neue und wiederkehrende Besucher und Rechenzeitersparnis für wiederkehrende Besucher - können wir TLS False Start verwenden, eine optionale Protokollerweiterung, die es dem Absender ermöglicht, Anwendungsdaten zu senden(Abbildung 4-10), wenn der Handshake nur teilweise abgeschlossen ist.

Abbildung 4-10. TLS-Handshake mit falschem Start

False Start ändert nicht das TLS-Handshake-Protokoll, sondern beeinflusst nur den Zeitpunkt, an dem die Anwendungsdaten gesendet werden können. Sobald der Client den Datensatz ClientKeyExchange gesendet hat, kennt er bereits den Verschlüsselungsschlüssel und kann mit der Übertragung der Anwendungsdaten beginnen - der Rest des Handshakes wird damit verbracht, zu bestätigen, dass niemand die Handshake-Datensätze manipuliert hat, und kann parallel durchgeführt werden. Mit False Start können wir den TLS-Handshake auf einen Roundtrip beschränken, unabhängig davon, ob wir einen vollständigen oder abgekürzten Handshake durchführen.

TLS-Datensatzgröße optimieren

Alle Anwendungsdaten, die über TLS übermittelt werden, werden in einem Datensatzprotokoll transportiert(Abbildung 4-8). Die maximale Größe jedes Datensatzes beträgt 16 KB, und je nach gewählter Verschlüsselung werden für jeden Datensatz zwischen 20 und 40 Byte Overhead für den Header, den MAC und optionales Padding hinzugefügt. Wenn der Datensatz dann in ein einziges TCP-Paket passt, müssen wir auch den IP- und TCP-Overhead hinzufügen: 20 Byte Header für IP und 20 Byte Header für TCP ohne Optionen. Das bedeutet, dass für jeden Datensatz 60 bis 100 Byte Overhead anfallen können. Bei einer typischen MTU-Größe (Maximum Transmission Unit) von 1.500 Byte auf der Leitung entspricht diese Paketstruktur mindestens 6 % des Overheads für das Framing.

Je kleiner der Datensatz ist, desto höher ist der Framing-Overhead. Es ist jedoch nicht unbedingt eine gute Idee, die Größe des Datensatzes einfach auf die maximale Größe (16 KB) zu erhöhen. Wenn sich der Datensatz über mehrere TCP-Pakete erstreckt, muss die TLS-Schicht warten, bis alle TCP-Pakete angekommen sind, bevor sie die Daten entschlüsseln kann(Abbildung 4-11). Wenn eines dieser TCP-Pakete verloren geht, umgeordnet oder aufgrund von Staukontrolle gedrosselt wird, müssen die einzelnen Fragmente des TLS-Datensatzes gepuffert werden, bevor sie entschlüsselt werden können, was zu einer zusätzlichen Latenz führt. In der Praxis können diese Verzögerungen zu erheblichen Engpässen für den Browser führen, der Daten bevorzugt im Streaming-Verfahren konsumiert.

Abbildung 4-11. WireShark-Aufnahme eines 11.211 Byte großen TLS-Datensatzes, aufgeteilt auf 8 TCP-Segmente

Kleine Datensätze verursachen einen Overhead, große Datensätze eine Latenz, und es gibt keinen einzigen Wert für die "optimale" Datensatzgröße. Für Webanwendungen, die vom Browser konsumiert werden, ist es am besten, die Datensatzgröße dynamisch an den Zustand der TCP-Verbindung anzupassen:

  • Wenn die Verbindung neu ist und das TCP-Überlastungsfenster niedrig ist oder wenn die Verbindung einige Zeit im Leerlauf war (siehe "Slow-Start Restart"), sollte jedes TCP-Paket genau einen TLS-Datensatz enthalten, und der TLS-Datensatz sollte die gesamte von TCP zugewiesene maximale Segmentgröße (MSS) belegen.

  • Wenn das Überlastungsfenster der Verbindung groß ist und wir einen großen Stream übertragen (z. B. Videostreaming), kann die Größe des TLS-Datensatzes auf mehrere TCP-Pakete (bis zu 16 KB) erhöht werden, um den Framing- und CPU-Overhead auf dem Client und Server zu reduzieren.

Hinweis

Wenn die TCP-Verbindung im Leerlauf war und selbst wenn Slow-Start Restart auf dem Server deaktiviert ist, besteht die beste Strategie darin, die Datensatzgröße zu verringern, wenn ein neuer Burst von Daten gesendet wird: Die Bedingungen können sich seit der letzten Übertragung geändert haben, und unser Ziel ist es, die Wahrscheinlichkeit der Pufferung auf der Anwendungsschicht aufgrund von verlorenen Paketen, Neuordnung und erneuten Übertragungen zu minimieren.

Die Verwendung einer dynamischen Strategie liefert die beste Leistung für interaktiven Datenverkehr: Eine kleine Aufzeichnungsgröße verhindert unnötige Pufferlatenz und verbessert die Zeit bis zum ersten [HTML-Byte, ..., Videobild], und eine größere Aufzeichnungsgröße optimiert den Durchsatz, indem sie den Overhead von TLS für langlebige Streams minimiert.

Um die optimale Datensatzgröße für jeden Zustand zu bestimmen, beginnen wir mit dem Ausgangsfall einer neuen oder untätigen TCP-Verbindung, bei der wir vermeiden wollen, dass sich die TLS-Datensätze über mehrere TCP-Pakete erstrecken:

  • Weisen Sie 20 Bytes für IPv4 Framing Overhead und 40 Bytes für IPv6 zu.

  • Weisen Sie 20 Bytes für den TCP-Rahmen-Overhead zu.

  • Weisen Sie 40 Bytes für den Overhead der TCP-Optionen (Zeitstempel, SACKs) zu.

Geht man von einer üblichen MTU von 1.500 Byte aus, bleiben 1.420 Byte für einen TLS-Datensatz, der über IPv4 übermittelt wird, und 1.400 Byte für IPv6. Um zukunftssicher zu sein, solltest du die IPv6-Größe verwenden, die 1.400 Byte für jeden TLS-Datensatz ergibt.

Als Nächstes kann die Entscheidung, wann die Aufzeichnungsgröße erhöht und zurückgesetzt werden soll, wenn die Verbindung im Leerlauf war, auf der Grundlage vorkonfigurierter Schwellenwerte getroffen werden: Erhöhe die Aufzeichnungsgröße auf bis zu 16 KB, nachdem X KB an Daten übertragen wurden, und setze die Aufzeichnungsgröße nach Y Millisekunden Leerlaufzeit zurück.

Die Konfiguration der TLS-Datensatzgröße lässt sich in der Regel nicht auf der Anwendungsebene steuern. Stattdessen handelt es sich oft um eine Einstellung und manchmal um eine Konstante zur Kompilierzeit für deinen TLS-Server. In der Dokumentation deines Servers findest du Informationen darüber, wie du diese Werte konfigurieren kannst.

Optimiere die Zertifikatskette

Die Überprüfung der Vertrauenskette erfordert, dass der Browser die Kette durchläuft, beginnend mit dem Zertifikat der Website, und rekursiv das Zertifikat der übergeordneten Organisation überprüft, bis er eine vertrauenswürdige Wurzel erreicht. Daher ist es wichtig, dass die angegebene Kette alle Zwischenzertifikate enthält. Fehlt eines, muss der Browser den Überprüfungsprozess unterbrechen und die fehlenden Zertifikate abrufen, was zusätzliche DNS-Abfragen, TCP-Handshakes und HTTP-Anfragen mit sich bringt.

Hinweis

Woher weiß der Browser, woher er die fehlenden Zertifikate abrufen soll? Jedes untergeordnete Zertifikat enthält normalerweise eine URL für das übergeordnete Zertifikat. Wenn die URL nicht angegeben wird und das erforderliche Zertifikat nicht enthalten ist, schlägt die Überprüfung fehl.

Umgekehrt solltest du keine unnötigen Zertifikate, wie z. B. die vertrauenswürdigen Wurzeln, in deine Zertifikatskette aufnehmen - sie fügen unnötige Bytes hinzu. Erinnere dich daran, dass die Server-Zertifikatskette als Teil des TLS-Handshakes gesendet wird, der wahrscheinlich über eine neue TCP-Verbindung erfolgt, die sich noch in der Anfangsphase des Slow-Start-Algorithmus befindet. Wenn die Größe der Zertifikatskette das anfängliche Überlastungsfenster von TCP übersteigt, fügen wir dem TLS-Handshake unbeabsichtigt zusätzliche Roundtrips hinzu: Die Zertifikatslänge übersteigt das Überlastungsfenster und veranlasst den Server, anzuhalten und auf eine ACK des Clients zu warten, bevor er fortfährt.

In der Praxis war die Größe und Tiefe der Zertifikatskette ein viel größeres Problem bei älteren TCP-Stapeln, die ihr anfängliches Überlastungsfenster auf 4 TCP-Segmente eingestellt hatten - siehe "Slow-Start". Bei neueren Einsätzen wurde das anfängliche Überlastungsfenster auf 10 TCP-Segmente erhöht und sollte für die meisten Zertifikatsketten mehr als ausreichend sein.

Überprüfe also, ob deine Server den neuesten TCP-Stack und die neuesten Einstellungen verwenden, und optimiere und reduziere die Größe deiner Zertifikatskette. Weniger Bytes zu senden, ist immer eine gute und lohnenswerte Optimierung.

OCSP-Heftung konfigurieren

Bei jeder neuen TLS-Verbindung muss der Browser die Signaturen der gesendeten Zertifikatskette überprüfen. Es gibt jedoch noch einen weiteren wichtigen Schritt, den wir nicht vergessen dürfen: Der Browser muss auch überprüfen, ob die Zertifikate nicht widerrufen wurden.

Um den Status des Zertifikats zu überprüfen, kann der Browser eine von mehreren Methoden verwenden: "Certificate Revocation List (CRL)", "Online Certificate Status Protocol (OCSP)", oder "OCSP Stapling". Jede Methode hat ihre eigenen Einschränkungen, aber OCSP Stapling bietet bei weitem die besten Sicherheits- und Leistungsgarantien - Details dazu findest du in den vorherigen Abschnitten. Achte darauf, deine Server so zu konfigurieren, dass sie die OCSP-Antwort der CA in die angegebene Zertifikatskette einbinden (stapeln). Auf diese Weise kann der Browser die Widerrufsprüfung ohne zusätzliche Netzwerktransfers und mit verbesserten Sicherheitsgarantien durchführen.

  • Die OCSP-Antworten können zwischen 400 und 4.000 Byte groß sein. Wenn du diese Antwort an deine Zertifikatskette anheftest, wird sie größer - achte also genau auf die Gesamtgröße der Zertifikatskette, damit sie das anfängliche Überlastungsfenster für neue TCP-Verbindungen nicht überfüllt.

  • Die aktuellen OCSP Stapling-Implementierungen erlauben nur die Einbeziehung einer einzigen OCSP-Antwort, was bedeutet, dass der Browser möglicherweise auf einen anderen Sperrmechanismus zurückgreifen muss, wenn er andere Zertifikate in der Kette validieren muss - was die Länge deiner Zertifikatskette verringert. In Zukunft sollte OCSP Multi-Stapling dieses spezielle Problem lösen.

Die meisten gängigen Server unterstützen OCSP-Heftung. Informiere dich in der entsprechenden Dokumentation über die Unterstützung und die Konfigurationsanweisungen. Wenn du dich für ein CDN entscheidest, überprüfe auch, ob dessen TLS-Stack OCSP-Stapling unterstützt und dafür konfiguriert ist.

Aktiviere HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security ist ein wichtiger Mechanismus für Sicherheitsrichtlinien, der es einem Ursprungsland ermöglicht, einem konformen Browser über einen einfachen HTTP-Header Zugriffsregeln mitzuteilen - z. B."Strict-Transport-Security: max-age=31536000".Damit wird der User-Agent angewiesen, die folgenden Regeln durchzusetzen:

  • Alle Anfragen an den Ursprung sollten über HTTPS gesendet werden. Dies gilt sowohl für die Navigation als auch für alle anderen Subressourcenanfragen gleichen Ursprungs. Wenn der Nutzer z. B. eine URL ohne https-Präfix eingibt, sollte der User Agent diese automatisch in eine https-Anfrage umwandeln; wenn eine Seite einen Verweis auf eine Nicht-HTTPS-Ressource enthält, sollte der User Agent diese automatisch umwandeln und die https-Version anfordern.

  • Wenn keine sichere Verbindung hergestellt werden kann, ist es dem Nutzer nicht möglich, die Warnung zu umgehen und die HTTP-Version anzufordern, d. h. die Herkunft ist nur HTTPS.

  • max-age gibt die Lebensdauer des angegebenen HSTS-Regelsatzes in Sekunden an (z. B. entspricht max-age=31536000 einer Lebensdauer von 365 Tagen für die ausgeschriebene Richtlinie).

  • includeSubdomains gibt an, dass die Richtlinie für alle Subdomains des aktuellen Ursprungs gelten soll.

HSTS wandelt den Ursprung in ein reines HTTPS-Ziel um und hilft, die Anwendung vor einer Vielzahl passiver und aktiver Netzwerkangriffe zu schützen. Als zusätzlichen Bonus bietet es auch eine nette Leistungsoptimierung, indem es die Notwendigkeit von HTTP-zu-HTTPS-Umleitungen eliminiert: Der Client schreibt automatisch alle Anfragen an den sicheren Ursprung um, bevor sie versendet werden!

Hinweis

Bevor du HSTS aktivierst, solltest du deinen TLS-Einsatz gründlich testen. Sobald die Richtlinie vom Client zwischengespeichert wurde, schlägt die Aushandlung einer TLS-Verbindung fehl, d. h. der Nutzer sieht eine Fehlerseite im Browser und kann nicht fortfahren. Dieses Verhalten ist eine ausdrückliche und notwendige Design-Entscheidung, um zu verhindern, dass Angreifer im Netzwerk Kunden dazu verleiten, ohne HTTPS auf deine Website zuzugreifen.

Aktivieren von HTTP Public Key Pinning (HPKP)

Einer der Mängel des derzeitigen Systems - wie in "Vertrauenskette und Zertifizierungsstellen"beschrieben - istunsere Abhängigkeit von einer großen Anzahl vertrauenswürdiger Zertifizierungsstellen (CAs). Einerseits ist das praktisch, weil wir so ein gültiges Zertifikat von einer großen Anzahl von Stellen erhalten können. Es bedeutet aber auch, dass jede dieser Stellen in der Lage ist, ein gültiges Zertifikat für unsere und jede andere Herkunft auszustellen, ohne dass sie ausdrücklich zugestimmt hat.

Hinweis

Die Kompromittierung der Zertifizierungsstelle DigiNotar ist eines von mehreren Beispielen, bei denen ein Angreifer in der Lage war, gefälschte, aber gültige Zertifikate für Hunderte von hochrangigen Websites auszustellen und zu verwenden.

Mit Public Key Pinning kann eine Website einen HTTP-Header senden, der die Browser anweist, ein oder mehrere Zertifikate in ihrer Zertifikatskette zu erinnern ("pinnen"). Auf diese Weise kann sie festlegen, welche Zertifikate bzw. Aussteller der Browser bei späteren Besuchen akzeptieren soll:

  • Das Ursprungsland kann sein Blattzertifikat anheften. Das ist die sicherste Strategie, weil du damit eine kleine Gruppe von Zertifikatsignaturen fest einträgst, die vom Browser akzeptiert werden sollen.

  • Der Ursprung kann eines der übergeordneten Zertifikate in der Zertifikatskette pinnen. Zum Beispiel kann der Ursprung das Zwischenzertifikat seiner Zertifizierungsstelle pinnen, was dem Browser mitteilt, dass er für diesen bestimmten Ursprung nur den von dieser Zertifizierungsstelle signierten Zertifikaten vertrauen soll.

Die Wahl der richtigen Strategie, welche Zertifikate gepinnt werden sollen, welche und wie viele Backups erstellt werden sollen, die Dauer und andere Kriterien für den Einsatz von HPKP sind wichtig und differenziert und würden den Rahmen dieser Diskussion sprengen. Weitere Informationen findest du in deiner Lieblingssuchmaschine oder bei deinem lokalen Sicherheitsguru.

Hinweis

HPKP bietet auch einen "Nur-Bericht"-Modus, der den angegebenen Pin nicht erzwingt, aber in der Lage ist, erkannte Verstöße zu melden. Dies kann ein guter erster Schritt sein, um deinen Einsatz zu validieren und Verstöße zu erkennen.

Website-Inhalt auf HTTPS aktualisieren

Um die besten Sicherheits- und Leistungsgarantien zu erhalten, ist es wichtig, dass die Website HTTPS verwendet, um alle Ressourcen abzurufen. Andernfalls gibt es eine Reihe von Problemen, die beides gefährden oder sogar die Website zerstören können:

  • Gemischte "aktive" Inhalte (z. B. Skripte und Stylesheets, die über HTTP übertragen werden) werden vom Browser blockiert und können die Funktionalität der Website beeinträchtigen.

  • Gemischte "passive" Inhalte (z. B. Bilder, Videos, Audiodateien usw., die über HTTP übertragen werden) werden zwar abgerufen, ermöglichen es dem Angreifer jedoch, die Nutzeraktivitäten zu beobachten und abzuleiten, und verschlechtern die Leistung, da zusätzliche Verbindungen und Handshakes erforderlich sind.

Überprüfe deine Inhalte und aktualisiere deine Ressourcen und Links, einschließlich der Inhalte von Drittanbietern, damit sie HTTPS verwenden. Der Mechanismus der Content Security Policy (CSP) kann hier eine große Hilfe sein, sowohl um HTTPS-Verstöße zu erkennen als auch um die gewünschten Richtlinien durchzusetzen.

Beispiel 4-1. 
Content-Security-Policy: upgrade-insecure-requests 1
Content-Security-Policy-Report-Only: default-src https:;
  report-uri https://example.com/reporting/endpoint 2
1

Weist den Browser an, alle (eigenen und fremden) Anfragen auf HTTPS umzustellen.

2

Weist den Browser an, alle Nicht-HTTPS-Verletzungen an den angegebenen Endpunkt zu melden.

Hinweis

CSP bietet einen hochgradig konfigurierbaren Mechanismus, um zu kontrollieren, welche Assets verwendet werden dürfen und wie und von wo sie abgerufen werden können. Nutze diese Möglichkeiten, um deine Website und deine Nutzer zu schützen.

Leistungs-Checkliste

Als Anwendungsentwickler sind wir von der Komplexität des TLS-Protokolls weitgehend abgeschirmt - Client und Server erledigen die meiste Arbeit für uns. Wie wir in diesem Kapitel gesehen haben, bedeutet das jedoch nicht, dass wir die Leistungsaspekte der Bereitstellung unserer Anwendungen über TLS ignorieren können. Wenn wir unsere Server so einstellen, dass sie wichtige TLS-Optimierungen ermöglichen, und unsere Anwendungen so konfigurieren, dass der Client diese Funktionen nutzen kann, zahlt sich das aus: schnellere Handshakes, geringere Latenzzeiten, bessere Sicherheitsgarantien und vieles mehr.

Deshalb hier eine kurze Checkliste, die du auf die Tagesordnung setzen kannst:

  • Erhalte die beste Leistung von TCP; siehe "Optimieren für TCP".

  • Aktualisiere die TLS-Bibliotheken auf die neueste Version und (re)baue die Server mit ihnen.

  • Aktiviere und konfiguriere Sitzungscaching und zustandslose Wiederaufnahme.

  • Überwache die Trefferquote deines Sitzungscachings und passe die Konfiguration entsprechend an.

  • Konfiguriere die Vorwärtsgeheimnis-Chiffren, um TLS False Start zu aktivieren.

  • Beende TLS-Sitzungen näher am Nutzer, um die Roundtrip-Latenz zu minimieren.

  • Nutze die dynamische TLS-Datensatzgröße, um Latenz und Durchsatz zu optimieren.

  • Prüfe und optimiere die Größe deiner Zertifikatskette.

  • Konfiguriere die OCSP-Heftung.

  • Konfiguriere HSTS und HPKP.

  • Konfiguriere die CSP-Richtlinien.

  • Aktiviere HTTP/2; siehe Kapitel 12.

Prüfung und Verifizierung

Um deine Konfiguration zu überprüfen und zu testen, kannst du einen Online-Dienst wie den Qualys SSL Server Test nutzen, um deinen öffentlichen Server auf gängige Konfigurations- und Sicherheitsfehler zu untersuchen. Außerdem solltest du dich mit der Befehlszeilenschnittstelle openssl vertraut machen, mit der du den gesamten Handshake und die Konfiguration deines Servers lokal überprüfen kannst.

Beispiel 4-2. 
  $> openssl s_client -state -CAfile root.ca.crt -connect igvita.com:443

  CONNECTED(00000003)
  SSL_connect:before/connect initialization
  SSL_connect:SSLv2/v3 write client hello A
  SSL_connect:SSLv3 read server hello A
  depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
          /CN=StartCom Certification Authority
  verify return:1
  depth=1 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
          /CN=StartCom Class 1 Primary Intermediate Server CA
  verify return:1
  depth=0 /description=ABjQuqt3nPv7ebEG/C=US
          /CN=www.igvita.com/emailAddress=ilya@igvita.com
  verify return:1
  SSL_connect:SSLv3 read server certificate A
  SSL_connect:SSLv3 read server done A 1
  SSL_connect:SSLv3 write client key exchange A
  SSL_connect:SSLv3 write change cipher spec A
  SSL_connect:SSLv3 write finished A
  SSL_connect:SSLv3 flush data
  SSL_connect:SSLv3 read finished A
  ---
  Certificate chain 2
   0 s:/description=ABjQuqt3nPv7ebEG/C=US
       /CN=www.igvita.com/emailAddress=ilya@igvita.com
     i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Class 1 Primary Intermediate Server CA
   1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Class 1 Primary Intermediate Server CA
     i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing
       /CN=StartCom Certification Authority
  ---
  Server certificate
  -----BEGIN CERTIFICATE-----
  ... snip ...
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 3571 bytes and written 444 bytes 3
  ---
  New, TLSv1/SSLv3, Cipher is RC4-SHA
  Server public key is 2048 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
      Protocol  : TLSv1
      Cipher    : RC4-SHA
      Session-ID: 269349C84A4702EFA7 ... 4
      Session-ID-ctx:
      Master-Key: 1F5F5F33D50BE6228A ...
      Key-Arg   : None
      Start Time: 1354037095
      Timeout   : 300 (sec)
      Verify return code: 0 (ok)
  ---
1

Der Kunde hat die Überprüfung der erhaltenen Zertifikatskette abgeschlossen.

2

Erhaltene Zertifikatskette (zwei Zertifikate).

3

Größe der empfangenen Zertifikatskette.

4

Ausgestellter Sitzungsidentifikator für zustandsabhängige TLS-Wiederaufnahme.

Im vorangegangenen Beispiel verbinden wir uns mit igvita .com über den Standard-TLS-Port (443) und führen den TLS-Handshake durch. Da s_client keine Annahmen über bekannte Stammzertifikate macht, geben wir manuell den Pfad zum Stammzertifikat an, das zum Zeitpunkt des Schreibens die StartSSL-Zertifizierungsstelle für die Beispiel-Domain ist. Dein Browser verfügt bereits über gängige Root-Zertifikate und ist daher in der Lage, die Kette zu überprüfen, aber s_client macht keine solchen Annahmen. Wenn du versuchst, das Root-Zertifikat wegzulassen, siehst du im Protokoll einen Überprüfungsfehler.

Ein Blick auf die Zertifikatskette zeigt, dass der Server zwei Zertifikate gesendet hat, die zusammen 3.571 Bytes ausmachen. Außerdem sehen wir die ausgehandelten TLS-Sitzungsvariablen - das gewählte Protokoll, die Verschlüsselung und den Schlüssel - und wir sehen auch, dass der Server eine Sitzungskennung für die aktuelle Sitzung ausgestellt hat, die in Zukunft wieder aufgenommen werden kann.

Get Leistungsstarke Browser-Vernetzung now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial