そろそろ標準化されるHTTP/2 ORIGIN フレームについて (RFC8336)

20180322 更新
RFC8336としてRFCになりました


HTTP/2の拡張仕様で、ORIGINフレームという提案仕様が大詰めを迎えています。
https://tools.ietf.org/html/draft-ietf-httpbis-origin-frame-05


IESGに送られていますが、現在のところでは反対意見は出ていません。

このORIGINフレームについては、数年前に一度記事を書きましたが幾つかの更新があるので補足する。
asnokaze.hatenablog.com

背景

HTTP/2では、上限があえば異なるオリジンとの通信でも1つのコネクションを使いまわすことが出来ます。

しかし、クライアントがコネクションを使いまわそうとしたものの、サーバ側がそのオリジンのコンテンツを提供できないという場合があります。その時は、サーバは421 (Misdirected Request)を返すことになっています。

421レスポンスを貰ってから再度目的のオリジンにコネクションをはるというのは、待ち時間を発生させます。

ORIGIN フレームは、サーバ側が対応しているオリジンのリストをクライアントに提供することで、クライアントはコネクションを再利用可能か判断出来るようにします。

HTTP/2 ORIGINフレーム

初期の提案仕様と異なり、複数オリジンをOrigin-Entryとして1つのフレームで送信できるようになっています

ORIGINフレームの中身はOrigin-Entryと呼ばれる領域が一つだけあります。

   +-------------------------------+-------------------------------+
   |         Origin-Entry (*)                                    ...
   +-------------------------------+-------------------------------+

Origin-Entryの中身は、通知するオリジンが長さと値を繰り返したものです。複数のオリジンを通知できます。

   +-------------------------------+-------------------------------+
   |         Origin-Len (16)       | ASCII-Origin?               ...
   +-------------------------------+-------------------------------+

ASCII-Originは、Scheme, Host, Portからなり、https://example.com:443 のように記述されます

クライアントはORIGINフレームで指定されたオリジンの場合のみそのコネクションを再利用できます。書かれてないものに関してコネクションを再利用しては行けません。

セキュリティ上の対応

セキュリティ上の対応で、初期提案と比べ変更点が有ります

  • クライアントはhttpsで接続している場合のみ、ORIGINフレームを解釈する。h2cの場合は無視する
  • *.example.comのようなアスタリスクは無効
  • alt-svcの広告の影響をうけない
  • コネクションを再利用するオリジン間でTLSハンドシェイク中に取得した証明書が有効なこと(subjectAltName or ワイルドカード証明書)

特に大きなトピックだったのは、クライントはORIGINフレームで提供されたオリジンの名前解決をすべきかどうかでした。

HTTP/2のコネクション再利用条件に、同じIPアドレスであることが条件の一つになっていますが、悪意あるサーバに悪用される可能性があるため、ORIGINフレームでもIPアドレスが同一かどうか確認するべきなのかが議論になりました。

今のところ、名前解決をしなくても良いことになっていますが、その場合はCTやOCSPをつかって証明書の確度をあげるべきだとしています。