Zusammenfassung

  • ALPN verlegte die Auswahl des Anwendungsprotokolls in den TLS-Handshake. Der Client nennt eine geordnete Menge, der Server wählt daraus genau einen gemeinsamen Wert nach eigener Präferenz.
  • Eine Registrierung ordnet einer opaken Bytefolge eine Spezifikation zu. Sie beweist weder Unterstützung noch Nutzung, und ein vorhandener Eintrag kann für einen bestimmten Kontext ausdrücklich unzulässig sein.
  • Die Auswahl gehört zur Verbindung, nicht zur wiederaufnehmbaren TLS-Sitzung. Bei einem neuen Handshake ist der frühere ALPN-Inhalt irrelevant; ohne gemeinsamen Wert muss die Verbindung vor Anwendungsdaten scheitern.

Ein registrierter Name durfte trotzdem verboten sein

Das IANA-Register für TLS-Erweiterungen und ALPN Protocol IDs enthält bekannte Bytefolgen für http/1.1, h2 und h3. Es enthält außerdem h2c mit dem Hinweis, dass dieser Wert nicht in einer TLS-ALPN-Aushandlung auftreten darf.

Das Register löscht den Namen nicht, weil seine Aufgabe nicht darin besteht, jeweils nur empfohlene Produktionskonfigurationen abzubilden. Es verhindert Namenskollisionen, hält Referenzen fest und bewahrt die genaue Grenze. h2c bezeichnet eine cleartext-Variante; seine Reservierung verhindert, dass dieselbe Bytefolge später etwas anderes bedeutet.

Ein Eintrag belegt daher eine Zuweisung, keine Installation. Er zeigt nicht, ob Clients den Wert anbieten, Server ihn auswählen oder Verkehr ihn nutzt. Ebenso wenig bestätigt er Sicherheit oder Berechtigung. Diese Beweise entstehen erst in Handshake, Anwendung und Betriebsdaten.

ALPN verbindet beide Ebenen ohne sie zu vermischen: Das Register sagt, welche Bytes welchen spezifizierten Namen tragen. Die konkrete Verbindung sagt, welcher gemeinsame Name jetzt gilt.

Ein gemeinsamer Port brauchte einen gemeinsamen Parser

Portnummern dienten lange als praktische Abkürzung für Anwendungsprotokolle. Als mehrere geschützte Anwendungen dieselbe TLS-Infrastruktur und besonders Port 443 nutzten, reichte diese Abkürzung nicht mehr.

Eine Aushandlung nach TLS hätte einen zusätzlichen Round Trip gekostet. Eine Erkennung anhand der ersten Anwendungsbytes hätte konkurrierenden Parsern Daten gegeben, bevor Einigkeit bestand. ALPN benutzte stattdessen den ohnehin erforderlichen Handshake.

RFC 7301 lässt den Client in ClientHello eine Liste nichtleerer, opaker Protokollnamen senden. Der Server antwortet mit einer Auswahl. Vor dem ersten Anwendungsbyte besitzt die Verbindung damit eine gemeinsame Grammatik.

RFC 8170 ordnet den Schritt der HTTP/2-Einführung zu. Die TLS-geschützte Variante brauchte eine Auswahl ohne weitere Netzrunde und nutzte ALPN; Upgrade blieb bei der ungeschützten Variante. Später wurde ALPN zum primären Mechanismus für künftige HTTP-Versionen.

Das macht ALPN nicht zu einer HTTP-Berechtigung. Es beantwortet früher und enger, welcher Parser diese Verbindung übernimmt.

Zwei Präferenzen bildeten eine Schnittmenge

Der Client ordnet seine Namen nach eigener Präferenz. Der Server besitzt eine andere Rangfolge und soll seinen bevorzugten Wert aus der angebotenen Schnittmenge wählen. Der erste Clientwert ist kein Befehl.

So bleiben zwei Entscheidungssphären erhalten. Der Client begrenzt, was er verstehen kann. Der Server wählt innerhalb dieser Grenze, was er bereitstellt. Er darf keinen nicht angebotenen Wert erfinden; der Client darf die lokale Serverpolitik nicht überstimmen.

Die Antwort enthält genau einen Namen. Er ist für diese Verbindung verbindlich. Ein Server darf nicht h2 ankündigen und anschließend HTTP/1.1 sprechen. Eine ALPN-Antwort ist keine allgemeine Capability-Liste, sondern ein Commit für die Interpretation der folgenden Bytes.

Ohne Schnittmenge verlangt RFC 7301 den fatalen Alert no_application_protocol. Stilles Fallback würde einen sichtbaren Konfigurationskonflikt in eine semantisch geteilte Verbindung verwandeln. TLS könnte die Bytes korrekt schützen, während beide Enden sie verschieden verstehen.

RFC 9325 fordert ALPN-Unterstützung für moderne TLS-Implementierungen und strikte Durchsetzung der angebotenen Menge. Cross-Protocol-Angriffe zeigen, warum ein nicht angebotener Parser keine harmlose Kompatibilitätswahl ist.

Das Ticket besaß keine zukünftige Auswahl

Session Resumption spart kryptografische Arbeit. Der vorherige ALPN-Wert könnte wie ein naheliegender Bestandteil des wiederverwendbaren Zustands wirken. RFC 7301 zieht die Grenze anders: ALPN ist Eigenschaft der Verbindung, nicht der Sitzung. Bei Tickets und Wiederaufnahme zählen nur die neuen Handshake-Nachrichten.

Der Client kann inzwischen ein Protokoll entfernt haben. Der Server kann seine Präferenz geändert haben. Das Ticket kann bei einem anderen Knoten landen. Würde die alte Wahl mitreisen, erhielte ein Performance-Artefakt dauerhafte Macht über die Anwendungspolitik.

Eine wiederaufgenommene Verbindung darf deshalb einen anderen gemeinsamen Wert auswählen. Der Unterschied ist kein automatischer Fehler. Er muss anhand von Angebot, Serverinstanz und Policy-Version erklärt werden.

Das Ticket bleibt ein begrenzter kryptografischer Nachweis. Es authentisiert nicht eigenständig einen HTTP-Origin, erlaubt keine Ressource und beweist nicht, dass der frühere Backendpfad fortbesteht.

TLS 1.3 verschob die sichtbare Hälfte

Im ursprünglichen Aufbau standen Clientangebot und Serverauswahl in ClientHello und ServerHello. RFC 7301 nahm die Sichtbarkeit bewusst in Kauf, damit Netzkomponenten Verbindungen unterscheiden konnten, wenn der Port nicht mehr genügte. Zugleich warnte sie vor Profiling durch aussagekräftige Namen.

RFC 8446 verschob die Serverantwort in EncryptedExtensions. Diese Nachricht ist mit Handshake-Traffic-Keys geschützt. Das Clientangebot bleibt im gewöhnlichen ClientHello.

„ALPN ist sichtbar“ und „TLS 1.3 versteckt ALPN“ sind daher beide zu grob. Eine Aussage muss TLS-Version, Richtung und Beobachtungspunkt nennen. Die geschützte Antwort ist immer noch eine neue Verbindungsentscheidung und kein geerbtes Ticketfeld.

Auch Monitoring muss diese Entwicklung berücksichtigen. Ein passiver Sensor kann das Angebot sehen, aber die Auswahl nicht mehr. Endpoint-Logs können beide Werte festhalten, benötigen jedoch Zugriffsschutz und eine begrenzte Aufbewahrung.

HTTP/2 verlangte nach der Wahl noch eine Bestätigung

RFC 9113 verwendet h2 für HTTP/2 über TLS und schreibt ALPN vor. h2c darf in dieser Aushandlung gerade trotz seines Registereintrags nicht erscheinen.

Nach TLS senden beide Enden zusätzlich ein HTTP/2 Connection Preface. ALPN wählt die Grammatik; das Preface bestätigt, dass die angeschlossene Anwendung tatsächlich so beginnt, und setzt SETTINGS.

Ein Edge kann h2 richtig auswählen und den Stream dennoch an einen HTTP/1.1-Backend weiterreichen. Dann besteht die registrierte Bezeichnung, der erfolgreiche Handshake und zugleich ein fehlerhaftes Preface. Nur die verketteten Belege zeigen, dass nicht die Auswahl, sondern der interne Übergang scheiterte.

Umgekehrt ersetzt ein gültiges Preface nicht die Authentisierung oder Origin-Autorität. Jede Schicht muss ihre eigene Behauptung behalten.

Early Data blieb an die neue Grammatik gebunden

TLS 1.3 kann bei geeigneter Wiederaufnahme 0-RTT-Daten zulassen. Der Client sendet sie, bevor die neue Serverantwort vollständig vorliegt. Ändert sich ALPN, stammen die vorbereiteten Bytes aus einer anderen Sprache.

RFC 8446 verbietet deshalb eine automatische Wiederholung von Early Data, sofern die ausgehandelte Verbindung nicht dasselbe ALPN-Protokoll wählt. Gleichheit ist aber nur eine notwendige Bedingung. Sie beweist keine Idempotenz, keinen unveränderten Credential-Kontext und keine Exactly-once-Ausführung.

Die Anwendung entscheidet über Replay. TLS verhindert lediglich, dass seine eigene Automatik Daten über einen erkannten Grammatikwechsel trägt.

Diese Grenze ist wichtig für Governance: Ein Infrastrukturteam darf aus einem gleichen Registerwert keine Geschäftsfreigabe ableiten.

QUIC fügte die Transportversion zur Schnittmenge hinzu

RFC 9001 verlangt für QUIC authentisierte Aushandlung des Anwendungsprotokolls, gewöhnlich mit ALPN. Ohne Ergebnis wird die Verbindung sofort geschlossen.

Ein Anwendungsprotokoll kann außerdem seine zulässigen QUIC-Versionen begrenzen. Server und Client müssen eine unvereinbare Kombination zurückweisen. Ein gleicher Name reicht also nicht; die konkrete Transportinstanz muss seine Semantik tragen können.

Damit wird der registergestützte Name zu einem Baustein in einer lokalen Entscheidung, nicht zu zentraler Zuteilung. Clientfähigkeit, Serverpolitik und Transportversion müssen sich auf dieser Verbindung treffen.

Das bewusste Verfallsdatum der Auswahl ermöglicht Wandel. Namen bleiben stabil, Tickets bleiben nutzbar, doch jede neue Verbindung kann eine aktualisierte Schnittmenge bilden oder vor Anwendungszustand scheitern.

Ein erfolgreicher Handshake war noch kein Dienstnachweis

In gemeinsam betriebener Infrastruktur stehen mehrere richtige Aussagen leicht nebeneinander: Die Adresse war erreichbar, das Zertifikat wurde akzeptiert, das Ticket konnte wiederaufgenommen werden und ALPN lieferte h2. Daraus folgt nicht automatisch, dass der konkrete Backendpfad für jeden Origin eingerichtet oder eine Anwendungshandlung autorisiert war.

Jeder Beleg besitzt einen anderen Schlüssel. Reachability gehört zum Pfad und Zeitpunkt. Zertifikatsprüfung gehört zu Name, Credential und Trust Policy. Das Ticket gehört zum kryptografischen Wiederaufnahmezustand. ALPN gehört zur Verbindung. Origin-Zuordnung und Nutzerberechtigung gehören zur Anwendung. Werden sie in einem einzigen Status „TLS erfolgreich“ verdichtet, verliert ein Incident genau die Trennlinien, die seine Ursache erklären.

Das wird während gestaffelter Rollouts sichtbar. Zwei Knoten können dasselbe Zertifikat und dieselben Ticket Keys verwenden, aber unterschiedliche ALPN-Präferenzen oder Backends besitzen. Ein Edge kann h2 auswählen, obwohl sein Ziel noch HTTP/1.1 erwartet. Umgekehrt kann eine technisch gültige HTTP/2-Verbindung eine Anfrage für einen bestimmten Origin ablehnen. Keine dieser Situationen wird durch den Registry-Eintrag oder den alten Ticketwert entschieden.

Ein belastbarer Nachweis verkettet daher Transport, Zertifikat, neues Angebot, Auswahl, Preface, internen Zielpfad und Autorisierung, ohne eine Stufe zur Stellvertreterin der nächsten zu machen. ALPN ist stark, weil sein Anspruch klein bleibt: ein gemeinsamer Parser für genau diese Verbindung.

Quellen

Diese Quellen belegen Standards, Empfehlungen und Zuweisungen, nicht aktuelle Verbreitung oder Produktkonfigurationen.