TLS 1.3 und HTTPS: Mehr Sicherheit und Geschwindigkeit für das moderne Web

TLS 1.3 ist die moderne Version des Protokolls, das die Verbindung zwischen Browser und Website schützt. Dank TLS werden Daten innerhalb einer HTTPS-Verbindung verschlüsselt übertragen: Ein externer Beobachter kann den Datenverkehr nicht einfach abfangen und Passwörter, Formularinhalte oder andere übermittelte Informationen lesen.

HTTPS ist dabei kein eigener Verschlüsselungsalgorithmus. Im Kern handelt es sich um gewöhnliches HTTP, das über einen geschützten TLS-Kanal läuft. Bevor Daten gesendet werden, müssen Browser und Server die Verbindungsparameter prüfen, sich auf kryptografische Algorithmen einigen und gemeinsame Schlüssel generieren.

Mit TLS 1.3 wurde dieser Prozess im Vergleich zu früheren Versionen deutlich vereinfacht. Veraltete Mechanismen wurden entfernt, die Anzahl der Nachrichten zwischen Client und Server reduziert und die Verschlüsselung der Protokollnachrichten beginnt früher. So ist modernes HTTPS gleichzeitig sicherer und schneller geworden.

TLS 1.3: Was ist das und welche Rolle spielt es bei HTTPS?

TLS steht für Transport Layer Security, also "Sicherheit auf Transportebene". Die Aufgabe: Einen sicheren Kanal zwischen zwei Teilnehmern der Verbindung herstellen - im Web meist zwischen Browser und Webserver.

Steht in der Adresszeile https://, baut der Browser zunächst eine TLS-Verbindung auf, bevor er HTTP-Anfragen darüber verschickt. HTTPS lässt sich daher als "HTTP im verschlüsselten Tunnel" vorstellen.

TLS löst mehrere Aufgaben gleichzeitig:

• Es verschlüsselt die übertragenen Daten, sodass deren Inhalt beim Abfangen nicht gelesen werden kann.
• Es ermöglicht dem Browser zu prüfen, ob er sich wirklich mit dem gewünschten Server verbindet.
• Es sichert die Datenintegrität und hilft, Manipulationsversuche während der Übertragung zu erkennen.

Worin unterscheidet sich TLS von HTTPS?

TLS ist nicht nur für Websites gedacht. Es ist ein universelles kryptografisches Protokoll, auf dem unterschiedliche Anwendungsprotokolle aufsetzen können. HTTPS ist lediglich eine der verbreitetsten Varianten.

Daher werden "HTTPS-Verschlüsselung" und "TLS-Verschlüsselung" oft synonym verwendet, auch wenn sie technisch unterschiedliche Ebenen beschreiben. HTTPS legt fest, wie Browser und Webserver Webdaten austauschen; TLS sorgt für die Sicherheit des Kanals, über den dieser Austausch stattfindet.

Beispiel: Der Browser kann eine Anfrage an eine Seite, eine API oder ein Bild per HTTP senden. Wird HTTPS genutzt, schützt TLS diesen Datenverkehr vor dem Versand und entschlüsselt ihn serverseitig nach Empfang.

Den gesamten Ablauf vom Adresseingabe bis zum Laden der Ressourcen finden Sie im Artikel Wie ein Browser eine Website lädt: Schritt-für-Schritt erklärt.

Welche Daten schützt TLS?

Nach Aufbau einer sicheren Verbindung verschlüsselt TLS alle Anwendungsdaten zwischen Client und Server. Dazu zählen unter anderem:

• Inhalte der aufgerufenen Seiten
• Logins und Passwörter
• Nachrichten und Kommentare
• Suchanfragen
• Formulardaten
• API-Anfragen
• Übertragene Dateien
• Cookies und weitere HTTP-Elemente

Bei korrekt konfiguriertem HTTPS sieht ein Angreifer, der Netzwerkpakete abfängt, keinen Klartext, sondern nur verschlüsselte Datenströme.

TLS macht den Nutzer jedoch nicht völlig anonym. Ein Beobachter kann weiterhin IP-Adressen, übertragene Datenmengen, Zeitpunkte und andere Metadaten sehen. Der eigentliche Inhalt des HTTPS-Verkehrs bleibt aber geschützt.

Warum ist gerade TLS 1.3 relevant?

TLS wurde über Jahrzehnte weiterentwickelt. Jede neue Version behebt Schwächen der Vorgänger. TLS 1.3 wurde 2018 standardisiert und ist eine grundlegende Neugestaltung, keine bloße Verbesserung von TLS 1.2.

Veraltete Algorithmen und statische Schlüsselaustauschmethoden wurden entfernt, die Zahl der Parameter-Kombinationen reduziert und der Verbindungsaufbau verändert. Nach dem ServerHello werden weitere Teile des Handshakes bereits verschlüsselt übertragen.

Dadurch benötigen Server und Browser weniger Schritte, um eine sichere Datenübertragung zu starten. Dieses neue Verbindungsmodell erklärt, warum TLS 1.3 deutlich schneller ist als frühere Protokollgenerationen.

Wie funktioniert HTTPS und wie wird eine geschützte Verbindung aufgebaut?

Gibt ein Nutzer eine Website-Adresse ein und drückt Enter, sendet der Browser Daten nicht sofort via HTTPS. Zuerst muss eine Netzwerkverbindung hergestellt und dann ein sicherer Kanal mit TLS aufgebaut werden.

Nachdem der IP-Adresse ermittelt ist, verbindet sich der Browser mit dem Server und startet das TLS-Handshake - die Aushandlung der Parameter für die sichere Verbindung.

Was passiert nach der Adresseingabe?

Der Ablauf in Kurzform: Der Browser sucht per DNS nach der IP des Domainnamens, verbindet sich mit dem Server und teilt ihm unterstützte TLS-Versionen und kryptografische Parameter mit.

Bei TLS 1.3 heißt die erste Nachricht des Clients ClientHello: Sie enthält die unterstützten Cipher Suites, Protokoll-Erweiterungen und Infos für den Schlüsselaustausch.

Der Server antwortet mit ServerHello und wählt passende Verbindungsparameter. Anschließend berechnen beide Seiten ein gemeinsames Geheimnis (Shared Secret), aus dem Schlüssel für die spätere Verschlüsselung abgeleitet werden.

Das Hauptunterscheidungsmerkmal von TLS 1.3: Schon im ersten Client-Nachricht werden fast alle Schlüsselaustauschdaten übertragen - zusätzliche Abstimmungsrunden wie bei TLS 1.2 entfallen.

TLS-Handshake einfach erklärt

Der TLS-Handshake ähnelt einem kurzen Sicherheitscheck vor einem vertraulichen Gespräch: Browser und Server prüfen, ob sie dieselbe Verschlüsselungsmethode verstehen, erzeugen ein gemeinsames Geheimnis und übertragen erst dann die Nutzdaten.

Der geheime Schlüssel wird dabei nicht direkt über das Netz verschickt. Beide Seiten tauschen offene kryptografische Parameter aus und berechnen daraus unabhängig dasselbe Geheimnis.

Typischerweise kommt bei TLS 1.3 der temporäre Diffie-Hellman-Schlüsselaustausch mit elliptischen Kurven zum Einsatz. Der Sitzungsschlüssel existiert nur für eine begrenzte Zeit und hängt nicht direkt vom privaten Zertifikatsschlüssel ab.

Nach erfolgreichem Handshake erhalten beide Seiten einen Satz symmetrischer Schlüssel, mit denen der eigentliche Datenstrom verschlüsselt wird - denn symmetrische Verschlüsselung ist wesentlich schneller als asymmetrische Verfahren.

Wie prüft der Browser das Website-Zertifikat?

Verschlüsselung allein genügt nicht: Der Browser muss sicherstellen, dass er sich mit der richtigen Website verbindet und nicht mit einem Angreifer.

Dafür verschickt der Server ein digitales Zertifikat mit Angaben zur Domain, öffentlichem Schlüssel und einer Signatur der Zertifizierungsstelle (CA).

Der Browser prüft, ob der Domainname passt, das Zertifikat gültig ist und ob eine vertrauenswürdige Zertifikatskette zur CA besteht, der das Betriebssystem oder der Browser vertraut.

Bei erfolgreicher Prüfung sieht der Nutzer keine Warnung. Ist das Zertifikat abgelaufen, für eine andere Domain ausgestellt oder nicht verifizierbar, erscheint eine Sicherheitswarnung.

Das Zertifikat dient primär zur Authentifizierung des Servers. Der eigentliche Datenverkehr wird nach dem Handshake mit separaten symmetrischen Schlüsseln verschlüsselt - nicht direkt mit dem öffentlichen Zertifikatsschlüssel.

Wie werden die Verschlüsselungsschlüssel vereinbart?

Modernes TLS 1.3 lässt Client und Server temporäre Schlüsselpaaren erzeugen und deren öffentliche Teile austauschen. Beide berechnen daraus unabhängig ein gemeinsames Geheimnis.

Ein Angreifer kann die offenen Parameter sehen, doch das reicht nicht, um den finalen Schlüssel zu rekonstruieren. Nach Abschluss des Austauschs werden daraus per spezieller Funktionen separate Schlüssel für verschiedene Phasen der Verbindung abgeleitet.

So wird die Sicherheit erhöht: Kein Schlüssel wird für alle Operationen verwendet. TLS 1.3 erzeugt getrennte Geheimnisse für das Handshake, den Anwendungsverkehr und andere Verbindungselemente.

Nach der Prüfung bestätigen beide Seiten, dass die Schlüssel korrekt sind und keine Nachrichten verändert wurden. Erst dann gilt die Verbindung als aufgebaut und HTTP-Anfragen können sicher im HTTPS-Kanal übertragen werden.

Wie verschlüsselt TLS 1.3 die Daten?

Nach Abschluss des TLS-Handshakes beginnt die Übertragung der verschlüsselten Nutzdaten. Ab diesem Punkt nutzt TLS 1.3 schnelle symmetrische Algorithmen - aufwendige Operationen mit privaten und öffentlichen Schlüsseln sind für jede Anfrage nicht mehr nötig.

Die Kombination aus asymmetrischer Kryptografie zum Vertrauensaufbau und symmetrischer Verschlüsselung für den Datenverkehr macht HTTPS sicher und alltagstauglich schnell.

Symmetrische und asymmetrische Verschlüsselung

Bei asymmetrischer Kryptografie gibt es ein Schlüsselpaar: öffentlich und privat. Sie ist ideal für die Authentifizierung und den sicheren Aufbau eines gemeinsamen Geheimnisses, aber viel rechenintensiver als symmetrische Algorithmen.

Daher wird der gesamte Webverkehr nicht mit dem öffentlichen Zertifikatsschlüssel verschlüsselt. Nach dem Handshake nutzen Browser und Server die gemeinsam erarbeiteten Geheimnisse und wechseln auf symmetrische Verfahren.

TLS 1.3 setzt auf aktuelle Authenticated Encryption-Algorithmen wie AES-GCM und ChaCha20-Poly1305. Diese verschlüsseln nicht nur die Inhalte, sondern stellen auch die Integrität der Daten sicher. Werden verschlüsselte Pakete unterwegs verändert, erkennt der Empfänger Manipulationen und verwirft die Daten.

Gerade für HTTPS ist das essenziell: Ein Angreifer darf nicht nur Passwörter nicht lesen können, sondern auch keine Anfragen oder Seiteninhalte unbemerkt verändern.

Warum sind temporäre Sitzungsschlüssel nötig?

Ein einziger dauerhafter Schlüssel für alle HTTPS-Verbindungen wäre ein großes Sicherheitsrisiko. Seine Kompromittierung würde erlauben, große Mengen früher aufgezeichneter Daten zu entschlüsseln.

In TLS 1.3 werden für jede Verbindung neue, nur für diese Sitzung gültige Geheimnisse erzeugt. Nach Verbindungsende werden sie nicht wiederverwendet.

Durch die verpflichtende Nutzung temporärer Schlüssel gewährleistet TLS 1.3 Forward Secrecy. Selbst wenn ein Angreifer später den privaten Zertifikatsschlüssel erhält, kann er damit keine früheren TLS-Sitzungen rekonstruieren.

Das unterscheidet TLS 1.3 von älteren Protokollen, bei denen die Kompromittierung des Server-Schlüssels auch vergangene Verbindungen gefährden konnte.

Was sieht der Provider bei einer HTTPS-Verbindung?

Die TLS-Verschlüsselung schützt den Inhalt des Datenverkehrs, aber nicht die Existenz der Netzwerkverbindung. Der Provider muss weiterhin wissen, wohin IP-Pakete geschickt werden - die Server-IP bleibt also sichtbar.

Auch Verbindungszeiten, Sitzungsdauer und grobe Datenmengen sind beobachtbar. Daraus lassen sich unter Umständen Rückschlüsse auf den Verkehr ziehen - aber einzelne HTTP-Anfragen oder Seiteninhalte bleiben verborgen.

Bei normalem HTTPS sieht der Provider nicht, was Nutzer in Formulare eingeben, welche Daten der Server im sicheren Kanal zurücksendet oder welche Cookies übertragen werden.

Einige technische Metadaten hängen vom eingesetzten Protokoll und weiteren Technologien ab. TLS ist daher als Schutz des Inhalts, aber nicht als Werkzeug für vollständige Anonymität zu verstehen.

Warum kann abgefangener HTTPS-Verkehr nicht einfach entschlüsselt werden?

Angenommen, jemand zeichnet alle Pakete zwischen Browser und Server auf - inklusive TLS-Handshake, verschlüsselter Daten und offener Netzwerkdaten.

Das genügt dennoch nicht, um den verschlüsselten Inhalt zu rekonstruieren. Die endgültigen Verschlüsselungsschlüssel werden nie direkt übertragen, sondern auf Basis des gemeinsamen Geheimnisses unabhängig berechnet - und das ist nicht allein aus den offenen Parametern rekonstruierbar.

Jeder Datenblock wird mit den Sitzungsschlüsseln verschlüsselt und auf Integrität geprüft. Bereits eine kleine Manipulation an einem Paket führt dazu, dass die Daten verworfen werden - unbemerktes Ändern ist unmöglich.

Angriffe auf modernes HTTPS zielen daher selten auf das "Knacken von AES", sondern auf andere Schwachstellen: Diebstahl von Schlüsseln, kompromittierte Geräte, Zertifikatsfehler, Serverlücken oder das Hereinlegen von Nutzern mit gefälschten Websites.

TLS 1.3 vs. TLS 1.2: Was hat sich geändert?

Lange war TLS 1.2 der Standard für HTTPS-Schutz, enthielt aber viele Mechanismen aus älteren Protokollgenerationen. Das erschwerte Serverkonfigurationen und ließ unsichere Krypto-Schemata weiter zu.

Mit TLS 1.3 wurde das Konzept geändert: Anstatt viele Kombinationen zu unterstützen, wurde die Anzahl der erlaubten Algorithmen reduziert und veraltete Verfahren entfernt.

Kürzeres Handshake

Eine der auffälligsten Änderungen ist das verkürzte TLS-Handshake. Bei TLS 1.2 benötigten Client und Server oft mehrere aufeinanderfolgende Nachrichtenwechsel, die jeweils durch die Netzwerk-Latenz verzögert wurden.

TLS 1.3 kann die wichtigsten Parameter schneller vereinbaren und Schlüssel generieren. In der Regel genügt nach Aufbau der Verbindung nur eine zusätzliche Netzwerk-Runde, um zur sicheren Übertragung der Anwendungsdaten überzugehen.

Je weiter der Server entfernt ist, desto größer macht sich der Unterschied bemerkbar - der Verzicht auf einen Nachrichtenwechsel spart bei hoher Latenz spürbar Zeit ein.

Entfernung veralteter Algorithmen

TLS 1.2 unterstützte viele Krypto-Mechanismen, darunter auch unsichere oder schwer sicher konfigurierbare Varianten. TLS 1.3 hat die Liste deutlich verkleinert und alte Schlüsselaustausch- und Verschlüsselungsverfahren gestrichen.

Das senkt das Risiko, dass ein Server zwar formal HTTPS unterstützt, aber schwache oder falsch konfigurierte Algorithmen nutzt. Moderne TLS-Versionen machen den sicheren Weg zur Basiseinstellung.

Forward Secrecy als Standard

Bei TLS 1.2 hing Forward Secrecy von der Cipher-Auswahl und Serverkonfiguration ab. Man konnte sowohl moderne temporäre Schlüssel als auch ältere Verfahren verwenden.

TLS 1.3 setzt temporäre Schlüssel als Standard um. Die Kompromittierung eines langfristigen privaten Schlüssels reicht nicht mehr aus, um frühere Sitzungen zu entschlüsseln - das ist besonders für den Webbereich entscheidend.

Weniger Varianten - weniger Fehler

Viele Konfigurationsoptionen bedeuten nicht zwangsläufig mehr Flexibilität, sondern auch mehr Fehlerpotenzial. In der Kryptografie erhöhen überflüssige Varianten das Risiko einer Fehlkonfiguration.

TLS 1.2 erlaubte viele Kombinationen von Schlüsselaustausch, Verschlüsselung und Integritätsprüfung. Administratoren mussten stets prüfen, welche davon sicher, veraltet oder nicht mehr zu empfehlen sind.

Mit TLS 1.3 wurde das Modell vereinfacht: Das Set an modernen Algorithmen ist kompakter, potenziell gefährliche Altlösungen wurden ausgeschlossen. Dadurch ist TLS 1.3 nicht nur kryptografisch besser, sondern auch weniger fehleranfällig.

Warum macht TLS 1.3 HTTPS schneller?

Verschlüsselung kostet Rechenleistung; früher galt HTTPS daher als merklich langsamer als reines HTTP. Heute sind Krypto-Operationen auf modernen Geräten kaum noch ein Problem - die meiste Verzögerung entsteht beim Verbindungsaufbau.

Genau hier punktet TLS 1.3: Es reduziert die Anzahl der Netzwerk-Runden, die vor der Übertragung nützlicher Daten nötig sind.

Was bedeutet 1-RTT?

RTT steht für Round Trip Time: die Zeit, die ein Paket für Hin- und Rückweg zwischen Client und Server benötigt. Bei 50 ms RTT dauert jede zusätzliche Nachrichtenrunde genauso lange, bis Daten übertragen werden können.

Das Standard-Handshake von TLS 1.3 gilt als 1-RTT - nach ClientHello und Server-Antwort liegen genug Daten für den Abschluss des Schlüsselaustauschs vor. Für Nutzer heißt das: Der Browser kann schneller HTTP-Anfragen senden.

Wie funktioniert Session Resume?

Besucht ein Nutzer eine Website mehrfach, baut der Browser oft neue Verbindungen auf oder kehrt nach kurzer Zeit zurück. TLS unterstützt das Wiederaufnehmen von Sitzungen: Nach erfolgreicher Verbindung kann der Server dem Client Daten zur Verfügung stellen, damit bei späteren Verbindungen nicht alles erneut ausgehandelt werden muss.

In TLS 1.3 ist dieses Feature in das neue Schlüsselaustauschmodell integriert und verkürzt die Verzögerung beim Wiederverbinden deutlich - besonders nützlich in Mobilfunknetzen, wo Verbindungen häufig abbrechen.

Was ist 0-RTT?

TLS 1.3 bietet zudem den besonders schnellen 0-RTT-Modus (Early Data): Bei erneuter Verbindung kann der Browser schon mit der ersten Nachricht Anwendungsdaten mitsenden, ohne das vollständige Handshake abzuwarten.

Der zusätzliche Netzwerkrunde entfällt quasi. Allerdings gibt es eine Einschränkung: Diese Daten könnten wiederholt abgespielt werden. Zwar kann ein Angreifer sie nicht einsehen, aber unter Umständen erneut senden.

0-RTT ist daher nicht für alle Aktionen geeignet - etwa nicht für Bestellungen, Geldtransfers oder andere nicht wiederholbare Transaktionen.

Wie spürbar ist der Geschwindigkeitsgewinn?

Im schnellen Heimnetz mit nahem Server beträgt der Unterschied zwischen TLS 1.2 und 1.3 oft nur wenige Millisekunden und fällt kaum auf.

Anders bei hoher Latenz, etwa über Mobilfunk zu einem Server auf einem anderen Kontinent: Bei 150 ms RTT spart der Wegfall einer Netzwerk-Runde bereits 150 ms beim Verbindungsaufbau.

Auf einer Seite gibt es meist mehrere Verbindungen (Hauptseite, CDN, API etc.), daher summieren sich kleine Verzögerungen schnell. Die Optimierung des Handshakes ist für globale Webdienste entscheidend.

Warum die Geschwindigkeit nicht nur von TLS abhängt

TLS 1.3 verkürzt die Wartezeit beim Aufbau einer sicheren Verbindung, macht aber eine langsame Website nicht automatisch schnell.

Die Gesamtgeschwindigkeit hängt von der Serverentfernung, Netzqualität, DNS, CDN, Seitengröße, Serverprocessing und genutztem Transportprotokoll ab.

Moderne Seiten setzen z. B. auf QUIC und HTTP/3, bei denen die Aufgaben von Transportschicht und Verschlüsselung noch enger verzahnt sind. Mehr dazu lesen Sie im Artikel QUIC-Protokoll: Die Zukunft des schnellen und stabilen Internets.

Das HTTPS-Tuning der heutigen Zeit ist also das Ergebnis mehrerer Neuerungen: TLS 1.3 beschleunigt das kryptografische Handshake, neue Transportprotokolle verringern weitere Verzögerungen zwischen Browser und Server.

Fazit

TLS 1.3 ist ein Meilenstein für HTTPS: Das Protokoll wurde vereinfacht, die Verbindungssicherheit erhöht und die Verzögerungen beim Aufbau einer sicheren Verbindung reduziert. Browser und Server benötigen weniger Nachrichten, und veraltete kryptografische Verfahren sind nicht mehr im Standard enthalten.

Für Nutzer bleibt der Ablauf nahezu unsichtbar: Nach dem Laden der Seite prüft der Browser das Zertifikat, führt den TLS-Handshake durch, generiert temporäre Schlüssel und überträgt den HTTP-Verkehr im verschlüsselten Kanal. So können Logins, Passwörter, Cookies, Seiteninhalte und andere sensible Daten nicht einfach durch das Abfangen von Netzwerkpaketen gelesen werden.

Trotzdem macht TLS 1.3 die Verbindung nicht anonym und löst nicht alle Performance-Probleme einer Website. IP-Adressen und einige Metadaten bleiben sichtbar, und die Gesamtleistung hängt auch von DNS, Serverentfernung, CDN, HTTP/2 oder HTTP/3 und der Netzqualität ab.

Das eigentliche Plus von TLS 1.3: HTTPS muss sich nicht mehr zwischen Sicherheit und Geschwindigkeit entscheiden. Die gesicherte Verbindung wird schneller aufgebaut, verwendet strengere kryptografische Mechanismen und passt besser zu den Anforderungen des modernen Internets.