Application Data Protocol

Kurz: Das TLS-Teilprotokoll, über das nach abgeschlossenem Handshake die eigentlichen Anwendungsdaten (z. B. HTTP-Anfragen) verschlüsselt übertragen werden.

Genauer: Sobald der Handshake abgeschlossen und der Sitzungsschlüssel etabliert ist, werden alle weiteren Daten der Verbindung als “Application Data” über das TLS Record Protocol verschlüsselt verpackt und übertragen. Für die darüberliegende Anwendungsschicht (z. B. HTTP) ist davon nichts sichtbar — sie sieht nur eine normale, aber eben verschlüsselte Verbindung.

Im Detail

Der Weg vom Klartext zum verschlüsselten Paket

Nach dem Handshake wechselt eine TLS-Verbindung in den “Application Data”-Zustand — ab diesem Punkt läuft jedes einzelne Datenpaket durch denselben Ablauf: Verschlüsseln mit dem ausgehandelten Sitzungsschlüssel, Anhängen eines Message Authentication Codes (MAC) bzw. Auth-Tags zur Integritätsprüfung, Verpacken in einen TLS-Record und Versenden über TCP.

Klartext (z. B. HTTP-Request)
  -> Verschlüsselung mit Sitzungsschlüssel (z. B. AES-256-GCM)
  -> MAC/Auth-Tag anhängen (Integritätsschutz)
  -> TLS-Record-Header (Typ 23 = Application Data, Länge)
  -> als TCP-Payload senden

Transparenz für die Anwendungsschicht

Der entscheidende Punkt: Für die Anwendung, die TLS nutzt (z. B. einen Webbrowser, der HTTP über HTTPS spricht), ist das komplett transparent — sie schreibt und liest ganz normale Bytes, ohne selbst etwas von Verschlüsselung, Records oder Sitzungsschlüsseln zu wissen. Das ist der Kernvorteil des Schichtenmodells: HTTP muss nichts über Kryptografie wissen, TLS muss nichts über HTTP wissen. Diese Trennung erlaubt es, praktisch jedes Protokoll “über TLS” zu betreiben — HTTPS (HTTP über TLS), aber genauso SMTPS, IMAPS, FTPS oder sogar beliebige TCP-basierte Protokolle, ohne dass diese selbst etwas an ihrer Logik ändern müssen.

Record-Größe und Fragmentierung

Records haben außerdem eine feste maximale Größe (16 KB, 2^14 Byte gemäß TLS-Spezifikation) — größere Datenmengen (z. B. eine große Datei) werden also automatisch auf mehrere Application-Data-Records aufgeteilt, jeder einzeln verschlüsselt und mit eigenem MAC versehen. Diese Fragmentierung hat praktische Sicherheitsauswirkungen: Bei komprimierten und gleichzeitig verschlüsselten HTTPS-Verbindungen konnte die Größe einzelner Records in der Vergangenheit Rückschlüsse auf den Inhalt zulassen (siehe der CRIME- und BREACH-Angriff, die die Kompression VOR der Verschlüsselung ausnutzten, um schrittweise geheime Tokens aus der Antwortlänge zu erraten) — moderne Server deaktivieren TLS-Kompression deshalb standardmäßig.

0-RTT-Daten in TLS 1.3

TLS 1.3 führte zusätzlich sogenannte “0-RTT”-Daten (Zero Round Trip Time) ein: Bei einer Wiederverbindung zu einem bereits zuvor besuchten Server kann der Client bereits mit der allerersten Nachricht Application Data mitschicken, noch bevor der Handshake formal abgeschlossen ist — das spart eine komplette Netzwerk-Rundreise und beschleunigt Seitenaufrufe spürbar. Der Kompromiss: 0-RTT-Daten sind anfällig für Replay-Angriffe (ein Angreifer kann die allererste Nachricht aufzeichnen und später erneut senden), weshalb Server 0-RTT typischerweise nur für Anfragen ohne Seiteneffekte zulassen (z. B. GET-Requests, keine Zahlungsvorgänge).

Abgrenzung zu anderen TLS-Teilprotokollen

Application Data ist eines von vier TLS-Teilprotokollen (neben Handshake Protocol, Change Cipher Spec Protocol und Alert Protocol) — alle vier nutzen denselben Record-Layer-Mechanismus zum Verpacken, unterscheiden sich aber im Record-Typ-Byte, das dem Empfänger sagt, wie er den Inhalt interpretieren soll.

Siehe auch: TLS Record Protocol, Handshake