TLS Record Protocol

Kurz: Die unterste Schicht des TLS-Protokolls, die für die tatsächliche Fragmentierung, Verschlüsselung und Übertragung der Daten nach abgeschlossenem Handshake zuständig ist.

Genauer: Das Record Protocol nimmt Daten von den höheren TLS-Teilprotokollen (Handshake Protocol, Change Cipher Spec, Alert Protocol, Application Data Protocol) entgegen, teilt sie in Blöcke, verschlüsselt und signiert sie mit den im Handshake ausgehandelten Schlüsseln und reicht sie zur Übertragung an die Transportschicht (TCP) weiter. Auf Empfängerseite läuft der Vorgang umgekehrt: entschlüsseln, Integrität prüfen, an die passende obere Schicht weitergeben.

Im Detail

Das Record Protocol ist die gemeinsame “Verpackungsschicht”, durch die ALLE anderen TLS-Teilprotokolle laufen — auch der Handshake selbst wird formal schon als Record-Nachricht verpackt, nur eben noch unverschlüsselt, solange die Schlüssel noch ausgehandelt werden:

Höhere TLS-Schicht (Handshake/Alert/ChangeCipherSpec/Application Data)
        |
        v
  TLS Record Protocol: Fragmentieren -> Komprimieren (optional) ->
                        Verschlüsseln -> MAC/Auth-Tag anhängen
        |
        v
      TCP (Transportschicht)

Ein einzelner Record besteht aus einem Header (Typ des Inhalts, TLS-Version, Länge) gefolgt vom eigentlichen, verschlüsselten Nutzlast-Block. Die maximale Größe eines einzelnen Records ist begrenzt (16 KB) — größere Datenmengen (z. B. eine große heruntergeladene Datei) werden deshalb automatisch in mehrere aufeinanderfolgende Records aufgeteilt, die auf Empfängerseite wieder zusammengesetzt werden.

Bei TLS 1.3 wurde das Record Protocol gegenüber TLS 1.2 vereinfacht und beschleunigt: Ältere Versionen erlaubten z. B. optionale Kompression vor der Verschlüsselung, was sich später als Sicherheitsrisiko herausstellte (CRIME-Angriff, der aus der komprimierten Größe Rückschlüsse auf den Inhalt ziehen konnte) — TLS 1.3 verzichtet komplett auf Kompression auf dieser Ebene und reduziert die Anzahl unterstützter Verschlüsselungsverfahren auf eine kleine Liste als sicher geltender Optionen.

Authenticated Encryption (AEAD)

Moderne TLS-Versionen nutzen für die Verschlüsselung auf Record-Ebene fast ausschließlich sogenannte AEAD-Verfahren (Authenticated Encryption with Associated Data, z. B. AES-GCM oder ChaCha20-Poly1305) — diese kombinieren Verschlüsselung und Integritätsprüfung in einem einzigen kryptografischen Schritt, statt (wie ältere TLS-Versionen) beides getrennt zu handhaben (erst verschlüsseln, dann separat einen MAC anhängen). Das vermeidet eine ganze Klasse historischer Angriffe (sogenannte Padding-Oracle-Angriffe wie Lucky Thirteen oder POODLE), die genau aus der getrennten Verarbeitung von Verschlüsselung und Authentifizierung resultierten.

Sequenznummern gegen Replay-Angriffe

Jeder Record trägt implizit eine fortlaufende Sequenznummer in die Verschlüsselung ein (auch wenn sie nicht explizit im sichtbaren Header steht) — das verhindert, dass ein Angreifer einen abgefangenen, gültigen verschlüsselten Record einfach ein zweites Mal einspielen kann (Replay-Angriff), denn ein wiederholter Record mit “alter” Sequenznummer würde bei der Integritätsprüfung als ungültig erkannt.

Fragmentierung großer Datenmengen

Die 16-KB-Obergrenze pro Record hat praktische Konsequenzen für die Performance großer Downloads: Eine 10-MB-Datei wird beim Übertragen in mehrere hundert einzelne Records aufgeteilt, jeder mit eigenem Verschlüsselungs- und Integritätsaufwand. Server-Implementierungen optimieren diese Fragmentierung oft aktiv — kleinere Records am Anfang einer Verbindung sorgen dafür, dass der Browser mit dem Rendern einer Webseite beginnen kann, sobald die ersten Daten ankommen, statt auf einen einzelnen großen Record zu warten (“TLS Record Size Optimization”), während größere Records bei bereits etablierten Verbindungen den Overhead pro übertragenem Byte reduzieren.

Verhältnis zur Anwendungsschicht

Aus Sicht einer Anwendung, die TLS nutzt (z. B. ein Browser), ist das Record Protocol komplett unsichtbar — Anwendungscode sieht nur einen fertigen, bereits entschlüsselten Datenstrom, ähnlich einer normalen unverschlüsselten TCP-Verbindung. Diese saubere Trennung ist architektonisch bewusst so gestaltet: Sie erlaubt es, TLS als eigenständige Schicht zwischen Transport- und Anwendungsschicht zu betreiben, ohne dass jede einzelne Anwendung (HTTP, SMTP, FTP über TLS) ihre eigene Verschlüsselungslogik implementieren müsste — jede höhere Anwendung profitiert einfach von derselben, zentral gepflegten TLS-Implementierung im Betriebssystem oder in einer gemeinsam genutzten Bibliothek wie OpenSSL.

Siehe auch: TLS, Handshake Protocol