Zusammenfassung

  • RFC 2817 schlug vor, eine laufende HTTP/1.1-Verbindung per Upgrade auf TLS umzustellen. Unverschlüsseltes und verschlüsseltes HTTP könnten Port 80 teilen; der Server sähe das Feld Host vor der Zertifikatswahl.
  • Der RFC ließ https als eigenen URI-Namensraum bestehen und berichtete für gewöhnliches Websurfen von geringem Interesse an einer Alternative zu Port 443. RFC 2818 beschrieb den bekannten Weg mit TLS als erstem Schritt auf diesem Port.

Das Web hatte zwei Eingänge beschriftet. Eine gewöhnliche HTTP-Anfrage ging durch Port 80. Bei https führte der Standardweg zu Port 443: zuerst der TLS-Handshake, dann die HTTP-Anfrage im geschützten Kanal. Im Dezember 1997 bekräftigte die Anwendungsleitung der IETF den Wunsch, neuen Protokollen künftig nicht jeweils einen normalen und einen sicheren Port zuzuteilen. Im Mai 2000 lag ein Verfahren auf dem Tisch, das beide Gespräche durch dieselbe Tür schicken wollte.

RFC 2817 setzte auf den HTTP/1.1-Mechanismus Upgrade: Eine bestehende TCP-Verbindung sollte von HTTP auf TLS/1.0 und danach wieder HTTP innerhalb von TLS wechseln. Das traf auch einen zweiten wunden Punkt. Beim namensbasierten virtuellen Hosting bediente eine IP-Adresse mehrere Hostnamen, die der Server aus dem HTTP-Feld Host erkannte. Beginnt TLS vor HTTP, muss die Zertifikatsentscheidung bereits fallen, ehe dieses Feld eintrifft. Ein offener erster Austausch könnte den Namen liefern und die Wahl vorbereiten. Erst am Empfang nach dem Namen fragen, dann die Tür verriegeln.

RFC 2616 beschrieb Upgrade als Wechsel zwischen unmittelbar verbundenen HTTP-Partnern. Darum konnte ein Client Upgrade: TLS/1.0 samt Connection: Upgrade an eine Anfrage hängen, wenn er auch eine offene Antwort akzeptierte. War eine offene Antwort unerwünscht, wies RFC 2817 ihn zu OPTIONS * als erstem Schritt an. Diese Anfrage klärte die Bereitschaft zum Wechsel, bevor eine empfindliche Operation verschickt wurde.

Bei Zustimmung sendete der Server 101 Switching Protocols, nannte die Reihenfolge TLS/1.0, HTTP/1.1 und begann unmittelbar nach den Antwort-Headern den TLS-Handshake. Erst danach setzte sich HTTP geschützt fort. Mit 426 Upgrade Required konnte der Server eine solche Umstellung verlangen. Die 426-Antwort war die Aufforderung; den Wechsel mussten die Partner anschließend tatsächlich aushandeln. Ein Schild „Tür bitte abschließen“ dreht keinen Schlüssel.

Proxys machten den Grundriss komplizierter. Upgrade galt pro Verbindungsetappe. Ein 101 zwischen Client und Proxy verschlüsselte die Strecke zwischen Proxy und Ursprung nicht automatisch. Für TLS bis zum Ursprung sah RFC 2817 zunächst einen CONNECT-Tunnel vor, sogar zum Zielport 80. Nach einer erfolgreichen 2xx-Antwort auf CONNECT konnte der Client den Upgrade-Austausch mit dem Ursprung führen. Die eine Portnummer sparte keinen Blick auf die Zwischenstationen.

Dann war da noch die Adresse selbst. RFC 2817 hielt http:// und https:// als getrennte URI-Räume fest. Der im selben Monat veröffentlichte RFC 2818 dokumentierte den https-Pfad: Standardport 443, TLS-ClientHello als Auftakt, HTTP erst innerhalb der sicheren Verbindung. Ein anderer Verbindungsablauf änderte die Technik an der Tür; die öffentliche Adresse sagte weiterhin, welches Haus gemeint war.

Der Vorschlag zeigte ungewöhnlich offen, wie seine Zeitgenossen reagierten. RFC 2817 meldete breite Zustimmung zur Grundidee, zugleich wenig Interesse an einem Ersatz für Port 443 beim allgemeinen Websurfen. Die Autoren sahen Chancen für neue auf HTTP aufbauende Protokolle, etwa Internet Printing. Damit standen Mechanik und Betriebspraxis im selben Dokument. Eine gemeinsame Tür konnte Portpaare vermeiden, dem Server den Hostnamen vor der Zertifikatswahl zeigen und TLS ausdrücklich verlangen. Das bereits verbreitete https hatte aber einen eigenen Namen, eine bekannte Portnummer und Gewohnheiten hinter sich. TLS klopfte an Port 80; die Einladung nannte 443.