Zusammenfassung

  • Die ursprüngliche Anfrage und die um Zertifikatsfelder ergänzte Anfrage beanspruchen nicht notwendig gleich viel Platz. Die Annahme am Proxy garantiert keine freie Kapazität am nächsten Empfänger.
  • DER-Binärgröße, unkomprimierte textuelle Feldgröße, übertragene Bytes und Kapazität einer dynamischen Kompressionstabelle sind unterschiedliche Maßstäbe.
  • Das Budget muss Zusätze und tatsächliche Empfänger berücksichtigen. Zertifikat oder Kette stillschweigend zu entfernen, kann eine Nachricht verkleinern, ohne ihre Bedeutung für die Anwendung zu erhalten.

Zwei erfolgreiche Schritte ergeben noch keine Kapazitätszusage

Angenommen, ein Client baut eine gegenseitig authentifizierte TLS-Verbindung zum Reverse-Proxy auf. Seine HTTP-Anfrage liegt innerhalb dessen, was der Proxy annimmt. Vor der Weiterleitung ergänzt der Proxy das Client-Zertifikat für die Anwendung. Nun empfängt das Backend eine Feldmenge, die größer sein kann als die ursprüngliche. Sie kann dessen Verarbeitungsgrenze überschreiten, obwohl der äußere Handshake nicht gescheitert ist.

Dieses Beispiel ist hypothetisch und wurde nicht getestet. Es schildert keinen Vorfall bei einem Anbieter. Es trennt zwei Entscheidungen über verschiedene Darstellungen: die Aufnahme des Zertifikats im äußeren Transport und die Aufnahme seiner Informationen in einer späteren HTTP-Nachricht. Erfolg beim ersten Schritt reserviert nicht automatisch Platz für den zweiten.

Der Client kann die ihm mitgeteilte Grenze eingehalten haben, während die Anwendung die ergänzte Anfrage ablehnt. Das ist kein logischer Widerspruch. Der Proxy hat die Nachricht verändert. Zu klären ist daher, wer das Wachstum zwischen Eingang und Ausgang berücksichtigt und welche Darstellung der jeweilige Empfänger zählt.

RFC9440 erschien im Juli 2023 als Informational-RFC der IETF, nicht als Spezifikation des Internet Standards Track. Es kodifiziert eine bestehende Praxis, um das Zusammenspiel unabhängig entwickelter Komponenten vorhersehbarer zu machen. Diese Interoperabilitätsabsicht ist weder eine Leistungsbewertung noch eine Bestätigung der Kapazität einer konkreten Installation.

Die Felder geben Informationen über das Zertifikat des ursprünglichen Clients aus dessen gegenseitig authentifizierter Verbindung zum TLS-terminierenden Proxy weiter. Weitere interne Verbindungen machen daraus keine Beschreibung des Zertifikats des letzten Hops. Die Anwendung kann die ursprüngliche Information nutzen, ohne dass die ursprüngliche TLS-Verbindung physisch bis zu ihr reicht.

Ein vertrauenswürdiger Weg bleibt Voraussetzung. Hier steht jedoch nicht erneut die vollständige Authentifizierungsgrenze im Mittelpunkt, sondern ihr zusätzlicher Kapazitätsvertrag. Auch eine korrekt geschützte Verbindung führt möglicherweise zu einem Empfänger mit zu kleinem Nachrichtenbudget. Vertrauenswürdige Herkunft gibt einer Darstellung keinen kostenlosen Platz.

Welche Bytes werden eigentlich gezählt?

RFC9440 übermittelt DER-kodierte X.509-Zertifikate als Byte Sequences von Structured Fields. Im textuellen Wert steht base64 zwischen Doppelpunkten, ohne eingebettete Leerzeichen oder Zeilenumbrüche. Das binäre Objekt und sein HTTP-Feldwert sind daher nicht gleich lang. Feldname, Begrenzung und gegebenenfalls Listensyntax kommen hinzu.

Die Größenbeziehung einer Kodierung lässt sich berechnen. Damit lässt sich bestimmen, welche Darstellung ein Budget aufnehmen müsste. Daraus folgt aber kein universeller Grenzwert, den jeder Empfänger akzeptieren müsste. Die Darstellung ist eine technische Tatsache; die zulässige Nachrichtengröße bleibt eine Entscheidung am zuständigen Empfangspunkt.

Bei der Feldkompression entsteht eine zweite Verwechslungsgefahr. HPACK oder QPACK rekonstruieren textuelle Namen und Werte. Der Zertifikatswert ist nach diesem Schritt weiterhin base64. Ihn anschließend zu DER-Binärdaten zu dekodieren, ist eine andere Operation. Wer die unkomprimierte Feldsektion anhand des kleineren binären Zertifikats zählt, hat mitten in der Prüfung die Einheit gewechselt.

Übertragung und gespeicherter Zustand sind nochmals andere Kosten. Ein kurzer Tabellenverweis kann einen langen Wert rekonstruieren. Ein als Literal gesendeter Wert muss nicht dauerhaft als Eintrag erhalten bleiben, ist aber weiterhin Teil der Anfrage. Weniger Bytes auf dem Draht bedeuten nicht automatisch weniger unkomprimierte Feldbytes, und weniger Tabelleneinträge schaffen nicht automatisch ein größeres Annahmebudget.

Die gemeinsame Sprache sollte deshalb die Darstellung, den Empfänger und die Nachricht benennen. Zertifikatsverwaltung, Proxybetrieb, Transportbetrieb und Anwendung können jeweils korrekte Messungen vorlegen und dennoch über verschiedene Ressourcen sprechen. Ein einzelner Ausdruck wie „Zertifikatsgröße“ verdeckt diese Aufteilung, statt sie zu lösen.

Fähigkeit des Parsers, Grenze des Dienstes

Structured Fields liefert einen präzisen, aber leicht falsch verwendeten Bezugspunkt. RFC8941 und sein Nachfolger RFC9651 verlangen von Byte-Sequence-Parsern Unterstützung für mindestens 16.384 Oktette nach binärer Dekodierung. Das ist eine Anforderung an den Datentyp, keine Verpflichtung eines HTTP-Servers, jede vollständige Anfrage mit einem solchen Objekt anzunehmen.

Nach HTTP-Dekompression enthält das Zertifikatsfeld weiterhin seinen base64-Text. Andere Felder, Namen, Trennzeichen und eine mögliche Kette bleiben ebenfalls vorhanden. Die Mindestfähigkeit in binären Bytes direkt als textuelles Headerlimit zu verwenden, verändert sowohl die Einheit als auch den Gegenstand. Unterstützung beim Interpretieren eines Wertes ist keine Zusage für die gesamte Nachricht.

Ein Parser kann die geforderte Fähigkeit haben, während die Anwendung für eine bestimmte Anfrage ein engeres betriebliches Limit setzt. Umgekehrt beweist eine großzügige Feldgrenze weder ein gültiges Zertifikat noch die gemeinte Identität oder eine erlaubte Operation. Größenzulassung und Vertrauensentscheidung sind getrennte Bedingungen, auch wenn sie nacheinander im selben Dienst auftreten.

Die angekündigte Grenze gilt nicht automatisch für alle Hops

RFC9110 setzt keinen gemeinsamen Maximalwert für alle HTTP-Feldzeilen, Werte oder vollständigen Sektionen voraus. Es berücksichtigt lokale Empfängergrenzen und verlangt eine geeignete 4xx-Antwort auf Anfragefelder, die größer sind als der Server verarbeiten möchte. Solche Felder einfach zu ignorieren, vergrößert laut Spezifikation die Anfälligkeit für Request Smuggling. Stilles Weglassen ist deshalb keine neutrale Größenbehandlung.

HTTP/2 verwendet SETTINGS_MAX_HEADER_LIST_SIZE. Nach RFC9113 hat dieser Wert beratenden Charakter. Gezählt werden unkomprimierte Namen und Werte in Oktetten, ergänzt um 32 Oktette pro Feldzeile. Für eine einzelne Anfrage darf der Empfänger eine niedrigere Grenze als angekündigt anwenden. Der unbegrenzte Anfangswert ist keine Beobachtung unbegrenzter Kapazität in einer konkreten Anwendung.

HTTP/3 nennt seinen Parameter SETTINGS_MAX_FIELD_SECTION_SIZE. RFC9114 zählt ebenfalls nicht komprimierte Namen und Werte mit 32 zusätzlichen Bytes pro Feld. Ein informierter Peer sollte die angegebene Größe nicht überschreiten. Die Spezifikation erklärt aber auch, dass jede beteiligte Implementierung ihre Grenze selbst anwendet. Ein Wert unter einer Ankündigung garantiert daher nicht die Annahme weiter hinten im Weg.

Die Parameternamen gehören zu ihren jeweiligen Protokollen und sollten nicht vertauscht werden. Keiner misst lediglich die Größe eines komprimierten Frames. Ein kleiner übertragener Block kann große Felder wiederherstellen, und eine protokollseitig passende Nachricht kann eine niedrigere Anwendungsschranke erreichen. „Welche Grenze wurde gelesen?“ reicht ohne Empfänger und Darstellung nicht aus.

Die Ankündigung bleibt hilfreiche Information, aber keine unwiderrufliche Reservierung für jede künftige Route. Wer eine Grenze als umfassende Zusage behandelt, überspringt die lokalen Annahmeentscheidungen, die das Protokoll ausdrücklich bestehen lässt. Das Problem verlangt Abstimmung über den tatsächlichen Weg, nicht nur die Kenntnis einer Zahl.

Der Zusatz braucht schon vorher Platz

Ein Proxy, der dem Client das gesamte Backendbudget anbietet, kann keinen Platz für seinen eigenen Zusatz übrig lassen. Die ursprüngliche Anfrage füllt möglicherweise den angekündigten Rahmen. Erst anschließend kommen Zertifikat und gegebenenfalls Kette hinzu. Die unveränderte Weitergabe desselben Limits an beiden Seiten koordiniert diese Transformation nicht.

RFC9440 empfiehlt deshalb einem Intermediär mit Größenankündigung, seine hinzugefügten Daten zu berücksichtigen und dem Client einen ausreichend kleineren Wert mitzuteilen. Es definiert dafür keinen überall identischen Abschlag und macht daraus keine neue universell zwingende Einstellung. Entscheidend sind die tatsächlichen Zusätze und der ausgewählte Empfänger.

Eine lokale Vereinbarung sollte die gezählte Darstellung, die Zusatzfelder und die Bedingungen einer Neubewertung benennen. Eine andere Validierungskette, ein neues Feld, eine veränderte Serialisierung oder ein anderer Empfänger kann den Abstand zwischen Ein- und Ausgang verändern. Das sind hier ungetestete Planungsfälle, keine dokumentierte Migration.

Ein Zertifikat kommt zudem nicht in einen leeren Rahmen. Die übrigen Client-Felder und weitere Proxyzusätze beanspruchen dasselbe Nachrichtenbudget. Die Analysierbarkeit eines einzelnen Wertes belegt nicht das Passen aller Kombinationen. Eine nachvollziehbare Reserve braucht daher ihren Geltungsbereich, statt als pauschale Absicherung jeder Zukunft dargestellt zu werden.

Optionalität bewahrt keine Bedeutung durch bloßes Weglassen

Client-Cert enthält das End-Entity-Zertifikat und ist nur für Anfragen bestimmt. Es ist ein Singleton, darf also weder eine Liste sein noch mehrfach auftreten. Client-Cert-Chain ist hingegen eine optionale Byte-Sequence-Liste in TLS-Zertifikatsreihenfolge. Sie wiederholt das bereits enthaltene Zertifikat nicht und darf ohne Client-Cert nicht erscheinen.

Optionalität erlaubt eine gewählte Konfiguration. Sie sagt nicht, dass eine Anwendung mit erwarteter Kette bei späterem Wegfall dieselben Eingaben bekommt. Eine Platzersparnis kann eine semantische Änderung sein. Der Größenbefund sollte deshalb nicht allein über die Gleichwertigkeit des neuen Betriebs entscheiden.

Das Wurzelzertifikat darf nach RFC9440 fehlen, wenn bekannt ist, dass der vorgesehene Originserver den ausgelassenen Vertrauensanker besitzt. Platzmangel erfüllt diese Bedingung nicht. Die Erlaubnis gilt auch nicht als allgemeine Einladung, nötige Kettenbestandteile so lange zu entfernen, bis die Nachricht passt. Sie betrifft Wissen über einen bestimmten Empfänger.

Die Kettenliste darf auf mehrere Feldinstanzen verteilt werden; der RFC nennt mögliche Kompressionsvorteile. Die Feldgrößenrechnung zählt jedoch für zusätzliche Zeilen erneut Namen und zeilenbezogenen Aufwand. Ein für Wiederverwendung günstiges Format kann einen anderen Zähler belasten. Diese Kostenverschiebung ist ein lokaler Abwägungsgrund, keine universelle Formatregel.

Die Tabelle ist ein eigener Ressourcenvertrag

RFC9440 beschreibt bedingt durch die Last eine mögliche Kompressionsschwäche: Verschiedene Clients teilen eine Proxy-Origin-Verbindung mit Feldkompression, ihre Zertifikatswerte sind groß und variabel. Das kann die Effizienz erheblich mindern. Es ist kein hier erhobener Flottenbefund und keine Aussage über jede denkbare Weiterleitung.

Der Originserver könnte seine dynamische Tabelle vergrößern. Hält der Proxy deren Größe für unzureichend, könnte er die Werte stattdessen immer als Literal übertragen und nicht in die Tabelle eintragen. Die beschriebenen Optionen gewichten gespeicherten Zustand und Wiederübertragung unterschiedlich. Keine wird als allgemein beste Einstellung vorgeschrieben.

HPACK berechnet nach RFC7541 einen Eintrag aus Namen und Wert vor Huffman-Kodierung plus 32 Oktetten. Der zulässige Höchstwert der Tabellenkapazität stammt aus dem verwendenden Protokoll; der Encoder kann weniger nutzen. Mehr Tabellenraum verändert diesen Zustandsspielraum, nicht automatisch die Feldgrenze einer Anfrage beim Empfänger.

Bei QPACK begrenzt der Decoder die maximale dynamische Kapazität über SETTINGS_QPACK_MAX_TABLE_CAPACITY. Ein Maximum von null verbietet nach RFC9204 Einfügungen. Der Parameter ist vom Feldsektionslimit von HTTP/3 zu unterscheiden. Daraus folgt weder ein Ausfall jeder Kompression noch die Behauptung, Zertifikatsanfragen würden stets blockiert. Eine universelle Empfehlung für diesen Wert wird hier nicht gegeben.

Wiederkehrende gleiche Werte und eine Folge unterschiedlicher Zertifikate bieten unterschiedliche Wiederverwendungschancen. Der Transportbetrieb kann diese Last berücksichtigen, ohne damit das Nachrichtenbudget der Anwendung festzulegen. Kompression, Speicher und Annahme sind verbundene Entscheidungen, aber keine austauschbaren Nachweise.

Eine kleinere Nachricht kann eine andere Nachricht sein

RFC6585 definiert 431 für zu große Anfragefelder, als Gesamtmenge oder als einzelnen problematischen Wert. Nach Verkleinerung ist erneutes Senden möglich; bei einem einzelnen Feld sollte die Antwort es benennen. Der Status ist jedoch optional. Unter Angriff kann ein Server Verbindungen verwerfen oder anders reagieren. Ein sichtbarer 431 ist nicht das garantierte Ergebnis aller Größenüberschreitungen.

Der Client kontrolliert möglicherweise nicht die Ergänzung durch den Proxy. Wiederholungen derselben Anfrage ändern deren Platzbedarf nicht. Das Entfernen eines Zertifikats könnte die Nachricht passend machen, aber auch die Eingabe der Anwendung für Authentifizierung oder Antwortauswahl verändern. „Passt jetzt“ ist kein Beleg gleichbleibender Bedeutung.

Es gibt legitime Anordnungen ohne diese Felder, etwa mit anderen Authentifizierungsverfahren. Gefordert ist keine universelle Ablehnung bei fehlendem Zertifikat. Gefordert ist eine erklärte Bedeutung der Abwesenheit, statt sie als Nebenprodukt der Größenbehandlung zu erfinden. Die zuständigen Teilnehmer müssen diese Anordnung verstehen und wählen können.

Auch Sitzungswiederaufnahme verlangt eine ausdrücklich gewählte Kontinuität. Einige TLS-Implementierungen behalten dabei Zertifikatsinformationen nicht. Kann eine Implementierung keine konsistenten Werte liefern, empfiehlt RFC9440 entweder das Abschalten der Wiederaufnahme für Zertifikatsverbindungen oder das anfängliche Weglassen eines später womöglich nicht verfügbaren Feldes. Das sind bedingte Entwurfsoptionen, keine Anweisung zur Änderung laufender Dienste und keine Aussage über jede Wiederaufnahme.

Antwortcache und Kompressionstabelle nicht verwechseln

Wenn Client-Cert die Antwort bestimmt, verlangt RFC9440 entweder deren Nicht-Speicherbarkeit oder durch Vary: Client-Cert beschränkte Wiederverwendung für denselben Wert. Sieht ein terminierender Proxy Zertifikatsfelder in Vary, sollte er dessen Wert zu * verändern, um Speicherung beim User-Agent zu verhindern. Antworten mit 431 dürfen nicht gecacht werden.

Dies sind Regeln für Antworten, nicht für Einträge in HPACK oder QPACK. Eine größere Tabelle erfüllt sie nicht. Ebenso wenig beweist eine kleinere Nachricht den vertrauenswürdigen Weg: Feldinjektion muss verhindert werden, die Annahme auf den vorgesehenen Weg beschränkt bleiben und die Kommunikation gegen unberechtigtes Mitlesen oder Verändern geschützt sein. Das Größenbudget ergänzt diesen Sicherheitsvertrag, ersetzt ihn aber nicht.

Quellen und Aussagegrenzen

Die Beispiele sind hypothetisch und nicht getestet. Grundlage sind veröffentlichte Spezifikationen, keine Produktionsmessungen. Es werden weder ein Vorfall noch voreingestellte Werte von Anbietern, ein universell sicherer Grenzwert, ein quantifizierter Leistungsgewinn oder abgeschlossene Negativtests behauptet. Betriebliche Vorschläge bleiben redaktionelle Schlussfolgerungen, getrennt von normativen Anforderungen.