Zusammenfassung

  • RFC 8879 erlaubt in TLS 1.3 CompressedCertificate statt Certificate, nachdem der empfangende Peer seine Dekompressionsalgorithmen genannt hat. Dieses Angebot gestattet eine Darstellung, beweist aber weder Nutzung noch einen unbegrenzten Ressourcenanspruch.
  • uncompressed_length muss exakt zur rekonstruierten Nachricht passen; die Ausgabe darf den Wert nie überschreiten. Der Empfänger kann unterhalb der 24-Bit-Grenze von TLS ein kleineres lokales Limit durchsetzen, bevor das Zertifikat den Peer authentisiert.
  • Erfolgreiche Dekompression ist keine Validierung. Belege trennen Angebot, Auswahl, komprimierte Bytes, deklarierte und wirkliche Länge, Rekonstruktionshash, geparste Kette, Vertrauensurteil, Alert, Fallback und Transportergebnis.

Zuerst wird über Ressourcen entschieden

Ein TLS-Terminator bearbeitet tausende neue Verbindungen. Der Client hat zlib, Brotli und Zstandard in ClientHello angeboten. Der Server wählt Brotli und sendet eine kleine Nachricht mit zwölf Megabyte deklarierter Ausgabelänge.

Das Certificate, das den Server vielleicht authentisiert, liegt noch verborgen im Payload. Der Client kann CA, Namen oder Public Key nicht als Rechtfertigung der ersten Allokation verwenden. Er prüft zunächst das eigene Angebot, wendet sein gewöhnliches Certificate-Limit an, begrenzt den Decoder und verlangt eine bytegenaue Länge.

Damit bleibt die Zuständigkeit klar. Der Sender wählt innerhalb der angebotenen Darstellungen. Der Empfänger bestimmt, welche Transformation er ausführt und welche Kosten eine noch nicht authentisierte Verbindung verursachen darf. Brotli anzubieten ist keine Übertragung der Speicherplanung.

TLS kann bis zu 16.777.215 Bytes darstellen, RFC 8879 erlaubt jedoch niedrigere Implementierungsgrenzen. Dieselbe Grenze gilt auf komprimiertem und normalem Pfad. Eine unkomprimiert zu große Kette darf nicht durch eine kleine Hülle zum Parser gelangen.

Angebot, Auswahl und Ergebnis sind getrennte Tatsachen

compress_certificate ist einseitig. Im ClientHello beschreibt es die Algorithmen für das Serverzertifikat; in CertificateRequest beschreibt der Server, wie er das Clientzertifikat empfangen kann. Eine bestätigende Antwort-Extension gibt es nicht.

Der Sender kann einen angebotenen Algorithmus wählen oder normales Certificate senden. Extension 27 in einem Trace beweist daher keine spätere Nachricht vom Typ 25. Offer-Zähler messen Fähigkeit, nicht Ausführung; Selection-Zähler beweisen noch keine erfolgreiche Rekonstruktion oder Validierung.

Auch die Richtung bleibt unabhängig. Ein Client, der komprimierte Serverzertifikate empfängt, muss sein eigenes Zertifikat nicht komprimieren können. Builds können RX und TX einzeln oder mit unterschiedlichen Algorithmusmengen aktivieren.

Der Mechanismus gilt ab TLS 1.3; bei TLS 1.2 wird die Extension ignoriert. Er ist nicht die allgemeine TLS-Record-Kompression. Nur eine Handshake-Nachricht erhält eine andere Darstellung, danach läuft die normale Zertifikatsprüfung.

Komprimiert wird die vollständige codierte Nachricht

Eingabe sind weder PEM-Dateien noch einzelne X.509-Objekte. Komprimiert wird das komplette Certificate mit Request Context, Zertifikatsliste und Extensions jeder Entry. Ändert eine andere Extension die Nachricht, gehören diese Bytes zur Eingabe.

Deshalb braucht die Evidenz zwei Hash-Ebenen. Der erste Hash identifiziert Algorithmus, Header und empfangenes Payload. Der zweite identifiziert die exakt rekonstruierte Certificate-Nachricht. Fingerprints von Leaf und Intermediates zeigen anschließend, welche Objekte die Validierung beurteilt hat.

Unterschiedliche Algorithmen erzeugen verschiedene Darstellungen derselben Eingabe. Auch ein Library-Upgrade kann andere komprimierte Bytes bei identischer Ausgabe liefern. Ein Payload-Hash allein stellt keine logische Gleichheit zwischen zlib, Brotli, Zstandard und dem normalen Pfad her.

Vorabkompression folgt derselben Bindung. OpenSSL kann Serverzertifikate vorab komprimieren und speichern. Client Certificate entsteht wegen des einmaligen Contexts aus CertificateRequest bei Bedarf. Ein Server-Cache ist an die gesamte Nachricht gebunden; Chain-Erneuerung, anderes Intermediate oder geänderte Entry-Extension machen ein altes Artefakt unbrauchbar.

Die deklarierte Länge ist eine Schranke

Decoderfehler, Ausgabe über dem deklarierten Wert oder eine abweichende Endlänge führen zu bad_certificate. Die Grenze muss während der Erzeugung wirken, nicht erst nach einer zu großen Allokation.

Das Längenfeld ermöglicht frühe Ablehnung, authentisiert aber weder den Absender noch den Inhalt. Ein protokollkonformer Wert kann für einen Dienst unter hoher Parallelität zu groß sein. Lokale Limits müssen aus gemessener Kapazität und Fehlertests folgen.

Kompression muss zudem nicht verkleinern. BoringSSL testet absichtlich schrumpfende, expandierende und zufällige Transformationen. Protokollgültigkeit bedeutet exakte Rekonstruktion innerhalb der Grenze; ein kleineres Payload ist ein Optimierungsziel.

Kompressionsrate, Sicherheit und Leistung sind daher getrennt zu messen: Deklaration, tatsächliche Ausgabe, Peak Allocation, Decoderzeit und Fehlerklasse. Eine hervorragende Rate kann Ressourcenstress verdecken, eine mäßige Rate ein entscheidendes Paket sparen.

Nach der Rekonstruktion beginnt die Vertrauensprüfung

Das rekonstruierte Certificate wird genauso behandelt wie eine normale Nachricht: Parsing, Kettenaufbau, Namen, Gültigkeit, lokale Policy und CertificateVerify im TLS-1.3-Transcript. Kompression repariert keine unbekannte CA und keine falsche Signatur.

Die Fehlerklassen bleiben getrennt. Nicht angebotener Algorithmus: Aushandlung. Overrun, Decoder oder Längenfehler: Rekonstruktion. Ungültige Struktur: Parsing. Chain oder Name: Validierung. CertificateVerify: Handshake-Authentisierung.

Ein gemeinsamer certificate_error verliert den entscheidenden Ort. Umgekehrt beweist decompression_success weder erwartete Identität noch Private-Key-Besitz oder Anwendungsbefugnis.

Running Code zeigt die Reihenfolge. BoringSSL baut zunächst Certificate und dessen Länge, ruft den gewählten Callback auf und serialisiert die komprimierte Nachricht. OpenSSL trennt RX, TX, Präferenz und Server-Precompression. IANA-Eintrag, verfügbare Codezeile und aktive Anwendungskonfiguration sind verschiedene Belege.

Erst das Gesamtergebnis macht gesparte Bytes wertvoll

Chains dominieren häufig den ersten Handshake. Weniger Bytes können Pakete oder einen Round Trip sparen, abhängig von Chain, Congestion Window, Verlust, CPU, Cache und gemeinsamem Algorithmus. PEM-Dateigröße ist kein Ersatz für die codierte Wire-Nachricht.

Angebot, Richtung, Algorithmus, Größen, Records, Pakete, Retransmissions, CPU, Speicher, Validierung und Endzeit gehören in einen Datensatz. Der Kontrollpfad nutzt dieselbe Zertifikatsidentität und Policy ohne Kompression.

Ohne gemeinsamen Algorithmus ist normales Certificate der vorgesehene Fallback. Mehr Fallback kann Client-Mix, fehlenden Decoder oder verschobene TLS-Terminierung anzeigen. Gleiche Limits und Validierung halten ihn zu einer Darstellungsänderung statt zu einem Sicherheitsdowngrade.

Quellen