Zusammenfassung

  • ALPN übermittelt das geordnete Angebot opaker Kennungen und lässt den Server einen gemeinsamen Wert auswählen. Die Auswahl gilt für die Anwendungsdaten dieser TLS-Verbindung, nicht für einen anderen Hop oder eine dauerhafte Serviceeigenschaft.
  • Ein terminierender Proxy ist downstream TLS-Server und upstream ein neuer TLS-Client. HTTP/2 unten und HTTP/1.1 oben können gleichzeitig korrekt sein; beide Verbindungen brauchen eigene Nachweise.
  • IANA-Eintrag, Konfiguration und installierter Callback zeigen Möglichkeiten. Laufzeitbeweis besteht aus Angebot, Auswahl oder Alarm, Callback-Ausführung, abgeschlossenem Handshake und Anwendungsstart mit derselben Connection-ID.

Die grüne Anzeige gehörte zum falschen System

Downstream war die Beweiskette vollständig: ClientHello bot zwei Werte an, EncryptedExtensions enthielt h2, Finished authentifizierte den Transcript, danach folgten HTTP/2-Preface und SETTINGS.

Der Origin war jedoch nicht der Peer dieser Verbindung. Das Edge entschlüsselte, öffnete eine neue TCP/TLS-Verbindung und verwendete andere Schlüssel, Zertifikate und Richtlinien. Upstream konnte http/1.1 ausgewählt werden; ohne ALPN konnte ein ausdrücklich konfigurierter HTTP/1.1-Fallback greifen.

Protokollübersetzung ist kein Fehler an sich. Der Fehler entstand, als Telemetrie beide Connection-IDs und das Terminierungsereignis entfernte und den Downstream-Wert in das Origin-Inventar schrieb. Ein enger Laufzeitfakt wurde zur unbelegten Topologieaussage.

Verhandelt werden Bytes

IANA weist application_layer_protocol_negotiation den Erweiterungswert 16 zu. RFC 7301 definiert jeden Namen als opake, nichtleere Bytefolge von einem bis 255 Oktetten mit Längenpräfix. Leere oder abgeschnittene Einträge sind ungültig.

Die Werte dürfen nicht kleingeschrieben, beschnitten oder unscharf verglichen werden. HTTP/2 über TLS verwendet exakt h2. RFC 9113 verbietet h2c im TLS-ALPN-Angebot und als Auswahl.

Die Reihenfolge beschreibt Client-Präferenz. Der Server wählt aus der Schnittmenge nach seiner Richtlinie. Ein zuerst angebotenes h2 ist keine Auswahl; ein konfiguriertes h2 ist kein Beweis, dass genau dieser Kontext lief.

Ohne Schnittmenge verlangt RFC 7301 den fatalen Alarm no_application_protocol. RFC 9325 empfiehlt die strikte Grenze gegen Cross-Protocol-Verwechslung. Einen nicht angebotenen Wert darf der Server nicht als Kompromiss einsetzen.

Definitiv innerhalb, bedeutungslos außerhalb

Nach erfolgreicher Auswahl ist der Wert für die Anwendungsdaten derselben Verbindung definitiv. Wer h2 auswählt, darf diesen Stream nicht als HTTP/1.1 lesen. HTTP/2 bestätigt den Start zusätzlich mit Connection-Preface und SETTINGS.

Angebot, Auswahl, authentifizierter Finished, gültiges Preface und erfolgreicher Request sind getrennte Stufen. Ein ClientHello beweist keinen Abschluss. ALPN ohne gültiges Preface beweist keinen laufenden HTTP/2-Dienst.

Auch zeitlich gibt es keine Garantie. RFC 9113 warnt, vergangene HTTP/2-Unterstützung sei kein starkes Signal für künftige Verbindungen, weil Instanzen, Konfiguration und Netzbedingungen wechseln. Die Verbindung ist deshalb die richtige Beweiseinheit.

Der Proxy führt zwei Protokollkonten

Gegenüber dem Browser ist der Proxy Server, gegenüber dem TLS-Origin Client. Jeder Hop hat eigenes Angebot, eigene Auswahl, Alarme und Policy-Generation.

Envoys offizielle Upstream-Optionen zeigen die Varianten: Downstream-Protokoll ausdrücklich übernehmen, HTTP/1.1 oder HTTP/2 upstream unabhängig über ALPN aushandeln oder ohne Upstream-ALPN auf HTTP/1.1 zurückfallen. Kontinuität ist ausgeführte Konfiguration, keine automatische Vererbung.

Ein Tunnel ist anders. Der Vermittler kann Bytes weiterleiten, ohne TLS-Endpunkt zu sein. Der Header aus RFC 7639 kann beabsichtigte Protokolle für CONNECT nennen, belegt aber keinen abgeschlossenen inneren Handshake.

Der Datensatz braucht daher zwei Tupel und ein benanntes Terminierungs-, Übersetzungs- oder Tunnelereignis. Die Verknüpfung verschmilzt ihre Autorität nicht.

Konfigurierter und ausgeführter Callback

Bei OpenSSL löscht eine Client-Liste mit Länge null das ALPN-Angebot. Enthält ClientHello kein ALPN, wird der Server-Callback nicht aufgerufen. Installation ist nur Fähigkeit.

Der Servername-Callback läuft vorher und kann SSL_CTX ersetzen; erst danach entscheidet ALPN. Die aktive Richtlinie kann somit vom virtuellen Host stammen, nicht aus einer global inventarisierten Liste.

SSL_get0_alpn_selected liefert geliehenen, nicht NUL-terminierten Speicher mit expliziter Länge. Wer daraus einen gewöhnlichen C-String macht, kann den Nachweis abschneiden oder verfälschen.

SSL_select_next_proto enthält eine wichtige Negativprobe: Ohne Überlappung steht trotzdem der erste Client-Wert in der Ausgabe, begleitet von OPENSSL_NPN_NO_OVERLAP. Im ALPN-Pfad muss die Ausgabe ignoriert werden. Erst loggen und dann den Rückgabecode prüfen erzeugt eine nie erfolgte Auswahl.

Fehlendes Angebot, ungültiger Vektor, keine Überlappung, NOACK, Callback-Fehler und Erfolg sind eigenständige Ergebnisse. Ein Boolesches Feld reicht nicht.

Resumption ist eine neue Verbindung

RFC 7301 macht ALPN zur Connection-, nicht Session-Eigenschaft. Bei Tickets und Wiederaufnahme sind frühere Werte irrelevant; der neue Handshake entscheidet.

Ein Ticket aus einer h2-Generation verpflichtet eine neue Instanz nicht. Alte Auswahlwerte in neue Telemetrie zu kopieren verdeckt Rollout-Änderungen.

Bei TLS 1.3 gehören ALPN-Parameter zur PSK für 0-RTT. Early Data darf nur angenommen werden, wenn die neue Auswahl passt. Wird sie abgelehnt und später ein anderes Protokoll gewählt, muss die Anwendung gegebenenfalls andere Nachrichten erzeugen.

RFC 9846 verbietet automatische Wiederholung durch TLS, sofern nicht dasselbe ALPN gewählt wird. Nur die Anwendung kennt Framing und Semantik.

Protokoll, Identität und Berechtigung

ALPN bestimmt, wie gesprochen wird. Zertifikatspfad und Service-Identity bestimmen, mit wem. Die Anwendung entscheidet, welche Handlung erlaubt ist.

HTTP/3 trennt dies deutlich: h3 wird gewöhnlich in TLS über QUIC gewählt, doch RFC 9114 verlangt zusätzlich ein passendes Zertifikat für den URI-Origin. Eine echte h3-Auswahl macht einen Server mit falscher Identität nicht autoritativ.

Auch der IANA-Eintrag belegt nur Bedeutung, nicht Deployment. Code und Konfiguration erklären Laufzeitdaten; sie ersetzen weder Angebot noch Auswahl oder Anwendungsstart.

Negativtests für eine ehrliche Zuordnung

h2,http/1.1 anbieten und serverseitig http/1.1 bevorzugen; Telemetrie muss den gewählten Wert speichern. Nicht angebotene Auswahl muss abbrechen.

ClientHello ohne ALPN senden und ausbleibenden Callback belegen. Fatalen no_application_protocol von absichtlichem NOACK trennen. OPENSSL_NPN_NO_OVERLAP auslösen, ohne dessen Ausgabe zu protokollieren. SSL_CTX durch SNI wechseln und die richtige Generation zuordnen.

Downstream h2 und upstream HTTP/1.1 mit beiden IDs und Übersetzung erzeugen. Nach Policy-Wechsel wiederaufnehmen, ohne den alten Wert zu erben. Bei geändertem finalem ALPN 0-RTT ablehnen und keine automatische Wiederholung zulassen.

Schließlich ALPN erfolgreich, Identität aber ungültig machen; danach beide erfolgreich, Anwendung aber ablehnend. Getrennte Resultate beweisen getrennte Autorität.

Quellen