要約

  • RFC 2817は既存のHTTP/1.1接続をTLSへ切り替え、平文と暗号化されたHTTPに80番ポートを共用させようとした。TLS開始前のHostで仮想ホストの証明書も選べた。
  • 同じ文書はhttpsのURIを独立したまま残し、2000年時点で一般的なWeb閲覧における443番の代案には実装上の関心が乏しいと記した。

二つの玄関を一つにすれば、案内係の仕事は減るはずだった。普通のHTTPは80番、httpsは443番。別のアプリケーションにも「通常版」と「安全版」でポートを二つずつ割り当てる癖が広がれば、番号札ばかり増える。1997年12月、IETFのアプリケーション分野の責任者らは、その慣行から離れる方針を再確認した。2000年に示された方法は、入場後に鍵を掛けることだった。

2000年5月のRFC 2817はHTTP/1.1のUpgrade: TLS/1.0を定めた。80番へ開いたTCP接続を、そのままTLSで保護する。名前による仮想ホストにも魅力があった。HTTP/1.1のHostは、同じIPアドレスのどのサイトを求めるかサーバーに伝える。一方、HTTPより先に始まる通常のTLSの握手では、当時の方式で証明書を選ぶための名前を受け取れなかった。最初の平文HTTPでHostを読めば、サーバーは適切な証明書を選んでからTLSを始められる。

その最初のやり取りには順番がある。RFC 2616でUpgradeは隣り合うHTTP相手同士の切替として定義された。平文の応答でもよい要求なら、クライアントは普通の要求でTLSを提案し、サーバーは平文で答える選択もできる。平文の答えが許されない場合、RFC 2817は先にOPTIONS *を送るよう求めた。大切な依頼を渡す前に、鍵を掛ける交渉だけを済ませる手順である。

サーバーが受け入れれば101 Switching Protocolsを返し、TLS/1.0, HTTP/1.1という順の層を示す。応答ヘッダーが終わったところで切り替わり、TLSの握手後にHTTPの会話が続く。サーバーから要求を突きつける426 Upgrade Requiredも定義された。426は必要な切替を示す札であり、クライアントは改めて所定のUpgrade交換を行う。札を掲げただけで扉に錠は掛からない。

プロキシがいると、玄関まで廊下が増える。Upgradeが効くのは一つの区間だけだ。プロキシが101を返せばクライアントとの区間、元のサーバーが返せばプロキシとの区間が変わる。RFC 2817は、終点までTLSを通すため、まずCONNECTでトンネルを開く方法を記した。行き先が80番でも同じだ。成功を示す2xxが来てから、そのトンネルの中で終点との切替を話し合う。一つのポートを使う構想にも、中継路の手続きは残った。

さらに、宛名は消せなかった。RFC 2817はhttp://とhttps://を異なるURIのまま扱う。同じ月のRFC 2818は、既に使われていたhttpsの方法を記録した。既定の443番に接続し、最初にTLS ClientHelloを送り、その後でHTTP要求を送る。URIのホスト名と証明書の照合も含まれる。通信の入口を一つにする設計と、利用者が場所を呼ぶ名前とは別々に定着していた。

RFC 2817の著者らは普及状況についても当時の見立てを書いた。共用案の考え方は受け入れられても、一般のWeb閲覧で443番を置き換える実装にはほとんど関心がなかったという。むしろインターネット印刷のようにHTTPを土台にする新しい用途に機会を見た。仕様書自身が、設計の美しさと既存の習慣の距離を測っていた。

80番の共用には理由があった。安全版ごとの新しいポートを節約し、Hostを先に読んで証明書を選び、426でTLSの必要性を示せる。ただし平文の前置き、101の受諾、プロキシのトンネル、そして独立したhttpsの宛名が一緒に付いてきた。TLSは80番へ訪ねていけた。443番にはもう地図上の住所があった。