「http://」も暗号化通信する仕様へ？　HTTPの「高速化」や「日和見暗号」の標準化議論

　今回は「HTTP」の動向について、2016年の大まかな流れと今後の予定を紹介する。

　ウェブの重要な技術の1つであるHTTPもIETFで標準化されている。HTTPに関する仕様はHttpbisワーキンググループ（WG）で議論されており、2015年春に、大きなパフォーマンス向上を実現する「HTTP/2」をRFC 7540として発行した。HTTP/2に関しては活発な議論が行われ、IETFの本会合のほか、中間会合も年に数回実施されていたが、2016年は中間会合は開催されておらず少々落ち着いた状況になっている。しかし、HTTPに対する改善は依然議論され続けており、落ち着いたと言ってもIETFの本会議ではいまだに1回の開催につき2回セッションを持つ議論量の多いWGでもある。

　たくさんの提案がある中、やはりパフォーマンスとセキュリティへの関心は高く、それらの改善仕様が多いかと思われる。パフォーマンスの改善は、主にラウンドトリップ回数を減らすもの、クライアント（ブラウザー）の待ち時間を短縮するものが挙げられる。セキュリティに関しては、暗号化に関するものや認証にかかわるものが挙げられる。

　実例を示したほうが分かりやすいので、そのうちいくつかを紹介したい。

HTTP Immutable Responses

　例えば、ブラウザーは画像やJavaScriptといったリソースをキャッシュする。リロードボタンを押すと、条件付きリクエストと呼ばれるHTTPリクエストを送信し、そのリソースが更新されているかサーバーに問い合わせる。変わっていないことが分かると、キャッシュしていたリソースを使用できるわけだ。しかし、ほとんど更新されないリソースではこの確認作業は無駄になってしまう。

　そこで、MozillaのPatrick McManus氏によって提案されている「HTTP Immutable Responses」という仕様では、ブラウザーのリロード時でも更新の確認なしにキャッシュを使用できるようにする。サーバーからHTTPレスポンスヘッダーで以下のようにcache-controlにimmutabaleを指定。immutableが指定された場合、ブラウザーは有効期限の間はサーバーに更新されているか問い合わせる必要がなくなる。

An HTTP Status Code for Indicating Hints

　HTTPレスポンスはステータスコード、レスポンスヘッダーの順番で構成されている。そのため、当たり前だがステータスコードが決定しないとレスポンスヘッダーを送信し始めることはできない。ステータスコードが決定するのは、コンテンツの生成が終わったあとのため、HTTPリクエストを受け取ってから比較的時間がたったあとになる。

　例えば、のちに必要になるリソースを読むようにブラウザーに指示する「Link: </main.css>;rel=preload」ヘッダーは、より早く応答したいレスポンスヘッダーの1つだ。FastlyのKazuho Oku氏によって提案されている「An HTTP Status Code for Indicating Hints」では、103ステータスコードを定義し、本来のステータスコードが決定する前に、特定のレスポンスヘッダーを返却できるようにする仕様だ。

　100番台のステータスコードはレスポンスが続くことを示しており、サーバー側から続けてHTTPレスポンスを返すことができる。103を使用した例は以下の図の通りだ。

　このようにして本来のコンテンツに先んじてレスポンスヘッダーを送信できるため、ウェブページの表示速度改善が期待される。また、HTTP/2対応リバースプロキシと組み合わせてServer Pushを送るユースケースが想定されている。

Opportunistic Security for HTTP

　背景から説明すると、2013年の「スノーデン事件」を受けてIETFでは「広域盗聴は攻撃である」という文書を出してる（RFC 7258）。HTTP通信でも、この盗聴行為を緩和する方法が議論さた。Mark Nottingham氏らによって提案されている
「Opportunistic Security for HTTP」では、「http://」で始まるURLでも暗号化通信をする仕様だ。「Opportunistic Security」は「日和見暗号」と呼ばれ、相手を認証しない暗号通信を示す。

　クライアントとサーバーがお互いにこの仕様に対応している場合は、「http://」のURLでもTLSで暗号化され通信される。

Secondary Certificate Authentication in HTTP/2

　HTTPSでは、一度TLSハンドシェイクを行ったあとにサーバーから追加の証明書を要求する場合がある。特定のURLにアクセスした場合にさらなるクライアント認証を必要とする場合だ。しかし、HTTP/2では、この仕組のために利用されていたTLSの再ネゴシエーションは禁止されている。再ネゴシエーションには脆弱性が見つかってるとともに、1つのコネクション上でHTTPリクエスト／レスポンスが多重化されているHTTP/2ではうまく追加のクライアント認証ができない。

　HTTP/2では仕様自体に拡張性があり、メッセージタイプ（仕様の用語でいうフレーム）の追加ができるようになっている。先の問題を解決するために、Mike Bishop氏らによって提案されている「Secondary Certificate Authentication in HTTP/2」では、HTTP/2自体に証明書を要求・送信する拡張メッセージを追加し、再ネゴシエーションといったTLSの仕組みを利用することなく追加の証明書のやりとりができるようになる。

「HTTP/3」はまだまだ先？

　今回は紹介しきれなかったが、Httpbis WGで議論されている仕様はまだまだたくさんある。例えば、Cookieの改善、コンテンツの圧縮効率改善、ServerPushの改善といった仕様が議論されている。比較的落ち着いてはきたが、HTTP自体の改善・拡張仕様は引き続き議論されるだろう。また、Httpbis WGとしても「QUIC」については注目されており、そちらへの貢献も行われると思われる。

　少し先の話をすると、時々冗談めかしく「HTTP/3」というキーワードが出てくることもあるが、まだまだ具体的な議論をする段階にはなっていない。当分は、引き続きHTTPの改善が進められるとは思うが、将来的にそういう話が出てくるのかもしれない。

　最後に、HTTPの仕様に興味を持った方は、ぜひHttpbisのドキュメントやメーリングリストを見てみてほしい。きっと興味深い話を見つけられると思う。