GREASE for HTTP/2 の提案仕様

AkamaiのMike Bishop氏から、「GREASE for HTTP/2」という提案仕様が出ています。

HTTP/2では、未知のフレームタイプとSETTINGSパラメータは無視するようになっています。これは、将来HTTP/2を拡張できるようにするためで、実際に「RFC 8336 The ORIGIN HTTP/2 Frame」では新しくORIGINフレームを定義しています。新しい機能をつかっても、未対応な実装にはただ無視されるだけですので、利用しやすいです。

本来は未知のフレームやSETTINGSは無視すべきですが、未知のSETTINGSパラメータによって通信を終了する実装があるようです(URL)。このような実装は、将来の拡張を妨げる原因になります。

そこで、HTTP/2にもGREASEを導入するのが今回の提案です。また、HTTP over QUICにおいても同様の仕組みが盛り込まれるかもしれません。

GREASE for HTTP/2

GREASEとは

TLSにおけるGREASE、「Applying GREASE to TLS Extensibility」についての解説が詳しいです
jovi0608.hatenablog.com

ちゃんと、未知のパラメータが無視されるように、GREASE用の意味を持たないパラメータを送信します。これによって、日頃から未知のパラメータを受け取っても不具合を起こさず無視する実装であることを確認します。

こうすることで、実際にプロトコルを拡張する前、実装者は未知のパラメータを受け取ったときに不具合があれば気づけるようになります。

GREASE for Frame Types

0xb + (0x1f * N) のフレームタイプをGREASE用に予約します。このフレームはまったく意味を持っておらず、PADDINGの代わりに使用できます。

具体的には、0x2A (42), 0x49(73), 0x68(104).... などのフレームタイプ番号です。

GREASE for SETTINGS

"0x?a?a" のSETTINGSパラメータをGREASE用に予約します。このSETTINGSはまったく意味を持っていません。

具体的には、0x0a0a (2570), 0x1a1a(6682), 0x2a2a(10793).... などのSETTINGSパラメータです。

Sec-Metadataヘッダについて

CSRF攻撃やクロスドメインリクエストに対してサイドチャネル攻撃をすることで、情報がリークすることがあります。

それを防ぐために、どのようにHTTPリクエストが行われたかサーバサイドでより詳しく判断できるように、Sec-Metadataヘッダという仕様がW3Cの WebAppSec WGで議論されています。仕様については提案者のMike West氏のリポジトリに説明があります「Sec-Metadata (TODO: Bikeshed the name)

すでに、Chromeへの導入も検討されています。
Intent to Implement: The `Sec-Metadata` HTTP request header.

例を見るとより分かりやすいと思います

Sec-Metadataヘッダ

たとえば、銀行のWebサイトで講座を操作するエンドポイント(リクエストをうけるURL)が、タグでクロスドメインでアクセスされることはないはずです。

Sec-Metadataヘッダは、そのHTTPリクエストがどのようなリクエストなのか情報を付加します。

以下は例です。

// <picture>
Sec-Metadata: initiator=imageset, destination=image, site=cross-site, target=subresource

// Top-level navigation
Sec-Metadata: initiator="", destination=document, site=cross-site, target=top-level, cause=user-activation

// <iframe> navigation
Sec-Metadata: initiator="", destination=document, site=same-site, target=nested, cause=forced
  • initiator及び、destininationは どのようにしてリクエストがトリガーされたかわかります。
  • targetは、browsing contextを示すtop-level, nested, subresourceのどれかになります
  • siteは、same-origin, same-site, cross-siteのどれかです
  • causeは、user-activation、forcedです。URLバーへの入力などユーザのアクションによってリクエストが行われたのか、window.locationなどユーザの意志とは別にリクエストが行われたのか識別できます

これらの情報を元に、サーバでは想定していないかどうか識別できるようになります。

Web5Gとはなんなのか

W3Cでは、「Web5G」を掲げ5G及び関連するネットワークの進化に向けて、それにあわせたWeb標準技術・APIを模索しているようである。

個人的な印象としては、ネットワークレイヤとWebアプリケーションレイヤが連携するようなイメージでいる。ネットワークを性能ごとに切り出して提供するネットワークスライスや、ネットワークエッジで処理を行うモバイルエッジコンピューティング(MEC)を具体的に想定しているものもあれば、そうでないものもある。

すでに幾つかの資料がネット上に上がっており、僕は5Gは全然詳しくないが、今回は「Web5G Roadmap」と「Web5G Workshop」を眺めつつ、どのような事が思い描かれているかみていく。

5Gとどのように関わるかわからないが、BBCのネットワークエッジまで HTTP over QUICマルチキャストで配信する例は非常に興味深い

Web5G Roadmap

W3Cのロードマップの中に「Web5G Roadmap」というページがある。既に標準化が進められている仕様の他に、「Features not covered by ongoing work」として将来思い描いている機能の一部が紹介されている。

特に「Network Control」に書かれている部分は興味深い

Real-time adaptative to live network conditions

エッジに設置され使用されるマルチアクセスエッジコンピューティング(MEC)によって、現在のネットワーク環境をリアルタイムにサーバ(クライアントへも?)に通知されるようなネットワークの登場が考えられている。そのときにブラウザはアプリケーションにどのような情報を提供すれば良いのか考えているようだ

セルラネットワークから、サーバへの情報提供可能にするメカニズムとプロトコルIETFで議論されているようだ。
Mobile Throughput Guidance Inband Signaling Protocol

Adaptation to cost of network operations

以前書いた、Mobile Data Plan Sharing APIのように、ユーザでデータPlanと連携する仕組み。ユーザが使っていない時にあわせてバックグラウンドで同期する仕組みなどを一般化できるか考えているようだ
asnokaze.hatenablog.com

Network-provided optimizations

WebRTCでは、アプリケーションプロパイダがNATやファイアウォールを超えるためのリレーサーバ(TURNサーバ)を提供しています。

ネットワーク事業者がこれらをサービスとして提供できるようなる仕組みが、「Operator-Assisted Relay Service Architecture (OARS)」で考えられている

Prioritization in enterprise networks

AppleCiscoは、ビジネスアプリケーションに最適化されたエンタープライズネットワークを提供するために協力してきました(URL)。これをWebアプリケーションへも拡張できるか?

Web5G Workshop

5/10 ~ 5/11にかけてイギリスで「W3C Web5G Workshop」が行われました。その資料が上がっているので幾つか絵を紹介する

Enabling the thrilling applications that will drive usage of 5G networks

Web技術やプロトコルの進化や利用の広がりがまとめられている(ppt URL)。その中で「Integration of the Network Protocol Layer」というスライド、Webとネットワーク制御レイヤが連携する図が出ている。

以下の図では2つの例が出ており、ブラウザからネットワークの情報を取得したりパラメータをセットする。

  • ブラウザから、Network Controle Endpointに対し現在のネットワーク状況を問い合わせ取得する。取得した情報をJavaScript APIでアプリケーションに提供する
  • ブラウザからNetwork Controle Endpointに対してnetwork adaptationを要求し、ネットワークに対してQoSが設定される

f:id:ASnoKaze:20180517012822p:plain

Network advances for Media: Server Push

BBCの発表(スライドURL)。動画は、MPEG-DASHでユニキャスト配信されており、その量が増えているという話のようだ。

そのなかで、ネットワークエッジにデバイスを設置し、そこまでマルチキャストで配信して、そこからユニキャストで配信などやっているようである。

BBCではQUICの利用を考えているようで、IETFでもQUICを用いたマルチキャストやサーバプッシュに関する拡張を提案している。

workshopでのこの一枚が象徴的で、ネットワークエッジまで HTTP over QUICマルチキャストで配信し、そこから先をユニキャストで配信することを考えているようである
f:id:ASnoKaze:20180517013810p:plain

Immersive Web & 5G

サムスンのWeb, XR, 5Gに関する発表(スライドURL)。

おそらく、低レイテンシで帯域が増えるとゲームやXRにとって良いという話

The evolution of the Web to enable greater network collaboration

IETFでのworkの話。レイヤが違くてあまり良くわからない...

Web5Gとはなんなのか

よく分からない

プロトコルにおける「堅牢性原則」は害悪か

Internet Architecture Board (IAB)でもあるMartin Thomson氏から「The Harmful Consequences of the Robustness Principle」という文書が提出されている。

これは、堅牢性原則(Robustness Principle)について言及している文書である

Robustness Principle

プロトコルの設計と実装に関する原則として、「送信するものに関しては厳密に、受信するものに関しては寛容に」と掲げる堅牢性原則(Robustness Principle)というものがある。

TCP/IP, SMTP, DNS, FTPなどの開発に関わった故ジョン・ポステル氏によって提唱され、ポステルの法則とも呼ばれている。

Wikipedia(ジョン・ポステル)によると

元々はポステルがTCPを規定した RFC793 において
相互運用性を確保するためにTCPの実装が持つべき性質として要約した節が
より一般化されて知られるようになったものである。

と書かれている。

当時の仕様の曖昧性や解釈の違い、実装のバグなどがあったとしても、極力通信が続けられるようにという原則である。プロトコルがデプロイされ使われるようにするため、このような原則となっている。

1996年に発行された RFC1958 Architectural Principles of the Internetでも「Be strict when sending and tolerant when receiving」と書かれている。

The Harmful Consequences of the Robustness Principle

提出された「The Harmful Consequences of the Robustness Principle」では、堅牢性原則(Robustness Principle)では、バグのある実装との通信を可能とするために受信側が寛容性を持つと、バグを定着させることになり、長期的なプロトコルのメンテナンス(拡張)を難しくすると述べています。

JSONの例があげられており、元の仕様であるRFC4627「The application/json Media Type for JSON」ではUnicodeの処理、オブジェクトメンバーの順序付け、数値のエンコーディングなど、詳細に書かれておらず、実装によってさまざまな解釈がされた。更新された RFC7159でも問題は解決されておらず、サブセットを定義し問題ある部分の仕様を禁止したRFC7493 I-JSON とも相互運用できていない。そのため、広くは使用されておらずJSONパーサは、[ECMA262]で指定されたより正確なアルゴリズムを実装している。

その他にもTLSのバグのある実装と通信を可能にするためのワークアラウンドが行われていることや、HTTP/1.1の仕様の曖昧性を無くすために数年の労力を要したことなどがあげられている。

そのためこの文書では、堅牢性原則(Robustness Principle)よりも、初期設計やデプロイを超えて長期的なプロトコルのメンテナンスの継続を推奨しています。

エラーハンドフィングとフィードバック

プロトコルのメンテナンスするうえで、実装しデプロイしている人からのフィードバックが重要です。

エラーハンドリングについては、仕様に不正状態の取扱について記述されていることが理想的です。そして実装は、エラー状態からの回復を試みるのではなく、致命的なエラーとすることでそれを改善する動機を与えます。

また、自動化されたエラーレポートの仕組みは、デプロイされたプロトコルのより良いフィードバックを得ることが出来ます。実装者に不具合をレポートする仕組みは優れていますが、ユーザのプライバシに留意する必要があります。

所感

ここ数年だけを外から見ても、ossification(骨化)と言われているように、プロトコルのメンテナンスに対するコストは上がっているように見える。エラーハンドリングやレポーティングの仕組みが充実していくのは非常に喜ばしい一方で、やはり実際に通信するためバグ実装に対するワークアラウンドが出てくるのはどうしても不可避に感じる。

HTTPの仕様改定がまた始まっているように、プロトコルのメンテナンスは継続して進めていかれるのは明らかであるし、続けていかなければならない。そのために、より良い仕組みや考え方が広まっていけばいいなあと思いました。

TLSにおけるTicketRequest拡張の提案仕様

Appleの人らによって「TLS Ticket Requests」という、TLSでのセッション再開に利用するチケットに関する拡張仕様が提案されています。

TLSはあまり詳しくないのですが簡単に読む

TLS session ticket

まず、TLS session ticketとセッション再開について確認する


TLSでは一度ハンドシェイクを行った相手と、セッションを再開するための手順が用意されています。これにより処理量を少なくできます。

セッション情報を暗号化しTicketとしてクライアントに渡すことで、サーバ側はセッション再開のために情報を保持しておく必要がなくなります。

Ticketに関する拡張仕様は、RFC5077「TLS Session Resumption without Server-Side State」で標準化されていますし、TLS1.3の仕様でもTicketに関する定義がされています。

  • TLS1.3の仕様では、最初のハンドシェイクの際にクライアントがFinishedを送った後に、サーバからNewSessionTicketメッセージでticketをクライアントに発行します。

f:id:ASnoKaze:20180415003935p:plain

  • 以降セッションを再開する場合は、pre_shared_key拡張を付与してセッションの再開を行います。セッションの再開ですので、サーバから「Certificate」「CertificateVerify」は送信されません。

f:id:ASnoKaze:20180415004050p:plain

TicketRequest概要

現在の仕様でも複数のticketを発行できますが、その発行する数はサーバが決めています。


Appleの人らが提案している「TLS Ticket Requests」では、クライアント側からticketを要求できるようになっています。これによって、クライアント側から必要なだけticketをサーバに要求できます。


例えばHTTPSなどの通信では、同じサーバに対して複数のコネクションをはる場合もあります。それはクライアントが並列数を選ぶので、欲しいticketの数をクライアントが決めるのは合理的です。


同じticketは1回のみ使用されるべきですので、クライアント側から要求すればticketが少なすぎることもなくなりますし、逆にサーバ側から過剰にticketを発行することも防げます。

TicketRequest拡張

ハンドシェイク時にticket_request(TBD)拡張を送ることで、TicketRequestに対応しているかネゴシエーションを行います。

お互いに対応していれば、ハンドシェイク後にTicketRequestメッセージを送ることでticketを要求できます。

   struct {
       opaque identifier<0..255>;
       opaque context<0..2^16-1>;
   } TicketRequest;

Cross-Origin Read Blocking (CORB) とは

ChromeにCross-Origin Read Blocking (CORB)という機能を実装するという議論が、blink-devのメーリングリストに投稿されています。

Cross-Origin Read Blocking (CORB)」 に詳しい説明があるので、CORB とはなんぞやと簡単に説明を読んで見る。

CORBはまだChromeで議論されている仕組みであり、他のブラウザやクライアントでそのまま適応されるものではない点注意

Cross-Origin Read Blocking (CORB)

CORBとは、一言でいうと、ある種の攻撃を防ぐために、画像デコーダJavaScriptエンジンがクロスオリジンのリソースを読み込む前にブロックする仕組みです。


imgタグやscriptタグは他のドメインのリソースを読み込むことが出来ます。これは、Cookieが付くのでそのユーザのみがアクセス出来るリソースだったり、そのユーザが属しているプライベートネットワークのみからアクセスできるリソースだったりします。

例えば、下記のように他ドメインjsonファイルを読み込むような下記要素を用意します

<script src = "https://example.com/secret.json">

XSSI攻撃といった、JavaScript Arrayコンストラクタを上書きすることで内容を読みとることができたり。その他にも多くの攻撃手法が見つかっています。(参考PDF)

また、img要素でも、ロードしメモリ上に配置された後にサイドチャネル攻撃でその中身を読み取る方法も可能性としてあります。

<img src="https://example.com/secret.json">

CORBはクロスドメインのリソースにおいて、JavaScriptエンジンや画像デコーダが受取る前に読み込みをブロックする仕組みのようです。

CORBにおけるブロック

CORBによって保護される必要があると判定された時、レスポンスは以下のように変更されます

対象となる読み込み方法

下記の手段で取得されるリソースが、CORB保護対象となり得る

  • XHR and fetch()
  • ping, navigator.sendBeacon()
  • <link rel="prefetch" ...>
  • “image” requests like <img> tag, /favicon.ico, SVG‘s <image>, CSS’ background-image, etc. script-like destinations like <script>, importScripts(), navigator.serviceWorker.register(), audioWorklet.addModule(), etc.
  • “audio”, “video” or “track”
  • “font”
  • “style”
  • “report” requests like CSP reports, NEL reports, etc.

<iframe>, <object>, <embed>は別のセキュリティで保護されており、別のプロセスで実行されるため推測は困難(らしい

レスポンスがCORBで保護されるかの条件

レスポンスがJSON、HTML、XMLの場合に保護対象になります。

  • X-Content-Type-Options: nosniffの場合、Content-TypeがHTML MIME type・JSON MIME type ・XML MIME type・text/plainの場合 (image/svg+xmlを除く)
  • レスポンスが206の場合、Content-TypeがHTML MIME type・JSON MIME type ・XML MIME typeの場合 (image/svg+xmlを除く)
  • それ以外の場合はレスポンスボディを確認します
    • HTML MIME type のうちHTMLとだと思われるもの
    • XML MIME typeのうちXMLだと思われるもの
    • JSON MIME typeのうちJSONだと思われるもの
    • text/plainのうちJSON, HTML, だと思われるもの

上記MIME typeの定義はこちら

demo

オプションを付けて起動すると動作するらしい
https://anforowicz.github.io/xsdb-demo/index.html

consoleに下記のように表示される

Blocked current origin from receiving cross-site document at https://www.chromium.org/ with MIME type text/html.
その他

ドキュメントには、現在のWebへの影響・互換性や、さらに詳しいアルゴリズムなどの解説などもある

Chromeにおいて非セキュアなHTTPで送信されたCookieの有効期限を短くする議論

暗号化してないHTTPで送信されたCookieの有効期限を短くしたいという議論は、Mozillaでも以前から行われてきました。「Intent to ship: Treat cookies set over non-secure HTTP as session cookies」。

もちろん、IETFでもMozillaのMartin Thomson氏らによって同様の提案がされています。
asnokaze.hatenablog.com

それに続く形で、Chromeでも非セキュアなHTTPで送信されたCookieの有効期限を短くするかという議論が行われています。

Intent to Deprecate: Nonsecurely delivered cookies.

Intent to Deprecate: Nonsecurely delivered cookies

この議論は、Webのセキュリティに関する標準化界隈で活発に活動されているGoogleのMike West氏によるMLへの投稿で始まっています。

非セキュアなHTTPで送信されたCookieの有効期限を、例えば1年にすることから初めて徐々に短くしていこうという話です。つまり、フルHTTPSにしてないサービスでは、ユーザは1年に1回ログインをし直す必要が出てきます。

(HSTSかsame-site属性がついてない場合は、第三者によって非セキュアなHTTPでCookieを送信させることが出来るのは、議論の一つとしてあります。)

送信されるCookieの何%が、非セキュアなHTTPで送信してからの時間が立っているかのパーセンタイルも共有されています。

Same-site Requests

  • 20% = 0-1 days
  • 40% = 2-3 days
  • 60% = 37-42 days
  • 80% = 120-135 days
  • 90% = 273-307 days
  • 93.88% = 345-388 days
  • 95% = 437-492 days
  • 99% = 701-789 days

Cross-site Requests

  • 20% = 2-3 days
  • 40% = 37-42 days
  • 60% = 95-107 days
  • 80% = 192-216 days
  • 90% = 307-345 days
  • 92.7% = 345-388 days
  • 95% = 437-492 days
  • 99% = 701-789 days

議論は始まったばかりですが慎重に進められていくでしょう。
Cookieのセキュリティに関する議論は根強く続けられていますが、すぐには解決できなく難しいですね。。。