Cross-Origin-Embedder-Policyヘッダについて

ChromeがCross-Origin-Embedder-Policy (COEP)の実装に着手しそうなので、ざっと仕様を眺める(議論段階であり、正式な仕様ではありません)
mikewest.github.io

ちょっと話が難しいので間違ってたらすみません。

なお以前は、仕様名は「Cross-Origin-Resource-Policy-Policy(CORP-P)」などとも呼ばれていた。仕様自体の議論や、名称の変遷については下記Issueを参照のこと
Opting into a CORS-only mode (Cross-Origin) · Issue #4175 · whatwg/html · GitHub

Cross-Origin-Embedder-Policy

Spectre攻撃以後、サイドチャネル攻撃を用いてメモリの内容を推測できる場合、Same-Originポリシーは十分ではないことがわかっています。つまり、ブラウザにクロスオリジンのリソースを読み込ませることに成功すれば、内容を推測できる可能性が出てきたわけです。

Cross-Origin-Embedder-Policyヘッダでは、埋め込むリソースがCross-Origin-Resource-Policyを明示するように強制します。また、そのためにCross-Origin-Resource-Policy: same-site (仕様上だとcross-originという表記もある)を指定できるように拡張します。

CORP自体は以前書いたとおりです
asnokaze.hatenablog.com


このドキュメントでは変更に合わせ、HTMLやFetchの仕様に対してモンキーパッチを当てています。

流れ

ブラウザは、example.comからhtmlファイルを読み込みます。このとき、レスポンスにCross-Origin-Embedder-Policy:require-corpヘッダがついています。これによって、サブリソースは Cross-Origin-Resource-Policyが必須になります。

サブリソースのレスポンスにCross-Origin-Resource-Policy:cross-siteとクロスオリジンでの読み込みを明示すると、ブラウザはそのリソースを読み込めるようになります。

f:id:ASnoKaze:20190623013333p:plain

安全なコンテンツを要求するPrefer:safeヘッダ

Webサービスによっては、子供に見せたくない有害なコンテンツを非表示にできるサービスもあります。

それの多くはcookieを使い、設定を保存するケースが多く個別に設定を有効にしていく必要があります。また、広告といった設定がし辛い部分もあります。

こういった要求をブラウザの設定でできるように、「The "safe" HTTP Preference」という提案がMark Nottingham氏から出されています。

この提案仕様は、「rfc7240 Prefer Header for HTTP」で定義されている、preferヘッダPreference-Appliedヘッダを使用します。

Prefer: safe

この仕様では、以下のように「Prefer: safe」をヘッダに指定することで安全なコンテンツを要求していることを示します。

   GET /foo.html HTTP/1.1
   Host: www.example.org
   User-Agent: ExampleBrowser/1.0
   Prefer: safe

もちろん、サーバが対応しているか、その要求を尊重するかは実装次第です。サーバはPreference-Appliedヘッダを使うことで、その要求を適応したことを示せます。

   HTTP/1.1 200 OK
   Transfer-Encoding: chunked
   Content-Type: text/html
   Preference-Applied: safe
   Server: ExampleServer/2.0
   Vary: Prefer

標準化

もちろん、安全なコンテンツを明確に仕様化することは難しいです。この提案仕様でもその曖昧性のためIESGからの承認が得られず標準とはなっていないと述べられています。

しかし、すでに実装があり有用性の観点からドキュメントとして提出されています。

サービスやリソースの廃止時間を示すSunset HTTP ヘッダ (RFC8594)

Webサービス、古いバージョンのWeb API、期限付きのデータなど、そのURLで提供しているリソースが将来的に廃止するということはよくあることです。

RFC 8594 「The Sunset HTTP Header Field」では、そのようなリソースの廃止時間をHTTPレスポンスヘッダで示せるようになります。

ただしこれはヒントに過ぎず、示した時間までの提供を保証するものではありません。

2016年から、10年間のみ保存されるデータなどには、下記のようなレスポンスヘッダをつけることで、2026年にリソースが取得できなくなることを示すことができます。
(フォーマットは、RFC7231 の通り 「Date/Time Formats」)

Sunset: Wed, 11 Nov 2026 11:11:11 GMT

廃止に関する追加の情報は、Linkヘッダで示すことができます。relation typeとして sunsetを指定します。

Link: <http://example.net/sunset>;rel="sunset";type="text/html"

このポリシーの中では、廃止の範囲(リクエストを受けたURLだけなのか、それとももっと広い範囲なのか)、廃止後の移行先などを書けます。

Cookie の SameSite=Lax をデフォルトにする提案仕様

20190823 追記
suidenOTI さまよりご指摘いただきました

不具合があったためChrome80でのリリースに延期になったようです。
https://www.chromestatus.com/feature/5088147346030592
https://www.chromestatus.com/feature/5633521622188032

20190523 追記
Firefoxでも同様の動きがあります
https://groups.google.com/forum/#!msg/mozilla.dev.platform/nx2uP0CzA9k/BNVPWDHsAQAJ


開催中のGoogle I/O で、SameSite属性のないCookieをSameSite=Laxとして扱うようにしていくという話があったようです
blog.chromium.org

SameSite=Laxになると、img, iframeやxhrなど送信される他サイトへのHTTPリクエストにおいてthird party cookieがつかなくなります。これによって、cookieの露出を控える事ができます。(SameSite = None とすることで引き続きトラッキングは可能)

Google調査によると SameSite属性のついたCookieはまだ0.1%以下であり、まだまだ普及できておらず、今回デフォルトでSameSite=Laxとする動きになったのだと思います。

この挙動は、すでにChrome Canaryでchrome://flagsより設定することができます。
f:id:ASnoKaze:20190509004402p:plain

提案仕様

また、上記のアナウンスに続いて、IETF側でもGoogleのMike West氏より「Incrementally Better Cookies」という提案仕様が出ております。

同氏がメーリングリスト投げた「Incremental improvements to cookies.」でも書かれている通り、Cookieを段階的に改善しようとしており、この仕様では

  • 1. デフォルトで、Cookieを「SameSite = Lax」として扱う
  • 2. 開発者が明示的に `SameSite = None`を設定することにより現状の振る舞いのようにできるが、そうするときは` Secure`属性が必要

にするという提案である。

同氏の関連活動

Mike West氏は、Cookieに関わる多くの改善を提案している

SameSite属性の仕様自体は「Same-Site Cookies」で書かれているが、下記の記事の通り、RFC6265bisに統合される流れである
asnokaze.hatenablog.com

また、新しい仕組みも検討中であったが、フィードバックをうけCookieを段階的に改善しようという流れのようだ
asnokaze.hatenablog.com

Cross-Origin-Opener-Policyについて

Cross-Origin-Opener-Policy (COOP)は現在、ChromeFirefoxで実装が進められている機能です。

仕様としては、whatwgで長らく議論がされており、おそらく仕様に入るでしょう

面白そうなので、簡単に読んで見る。今の所下記ドキュメントが定義のようだが、適宜議論を参照のこと

間違ってたらご指摘ください

Cross-Origin-Opener-Policy とは

ユーザがサイトAを閲覧しているとき

サイトA から サイトBをウィンドウとして開いた場合 (noopnerはつけてない)、Bはwindow.openerを介してAにアクセスすることができます(仮にAとBのオリジンが違っていても、制限はありますがAのプロパティにアクセスできます。)
f:id:ASnoKaze:20190508015638p:plain

このようなアクセスは、サイトのアイソレーション上好ましくありません。このようなことを防ぐために、Cross-Origin-Opener-Policyヘッダを利用します。もし、指定されたPolicyに合わない場合は、上記のような繋がりは解除されます(ウィンドウを閉じて開き直したのと同じ状態)

Cross-Origin-Opener-Policyは下記のような値を取ります。

Cross-Origin-Opener-Policy = same-origin
Cross-Origin-Opener-Policy = same-site
Cross-Origin-Opener-Policy = same-origin unsafe-allow-outgoing

A及び、Bそれぞれへのアクセスした際はポリシーに合わず、openerがnullを返すようになります

  • Aもしくは、BのどちらかのみにレスポンスヘッダでCross-Origin-Opener-Policyが設定される
  • AとBのCross-Origin-Opener-Policyのsameness (same-origin or same-site)が異なる
  • 値がsame-originだが、AとBのオリジンが異なる
  • 値がsame-siteだが、AとBのホスト名が異なる

こうすることで、noopenerを指定できる開く側だけでなく、開かれる側からもopenerのつながりを解除することができるようになります。(unsafe-allow-outgoingを指定すると開く側のときだけ許可する)

おまけ

議論の変遷のなかで、openerのポリシーへとヘッダ名とともに変遷しており、議論を追うのが大変だった...

新しいWebの双方向通信 "WebTransport" について

[2019/10/10] WebTransport over QUIC について追加で記事を書きました
asnokaze.hatenablog.com

>


<
WebTransportという新しい双方向通信フレームワークの議論が始まっている。

GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。
discourse.wicg.io

WebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。(実際に使用する"トランスポート"はプラガブルな設計になっている)

また、TCPとは異なり、パケロスしても再送を行わないPartial reliabilityなども使えるようになる。そのようなAPIも改めて定められる。

その他にもコネクションのマイグレーションをサポートしているトランスポートであればIPが変わってもコネクションを維持できる。

WEBRTC-QUICで同様のことは可能だが、ICEを必要とせずクライアント・サーバの通信ユースケースに絞っている。

QUICについては以前簡単に書いたとおり
asnokaze.hatenablog.com

仕様

すでにAPIプロトコルの仕様が書かれている。

API

WebTransport」として、WebRTC-QUICのリポジトリ下に、APIに関する仕様が書かれている。

その中で書かれている例の一つをとりあげると、再送を行わないメッセージの送信は以下のようになっている。

let transport = getTransport();
let messages = getMessages();
for (msg in messages) {
  transport.createSendStream({disableRetransmissions: true}).write({data: msg, finished: true});
}
プロトコル

プロトコルの仕様としてすでに下記の3つのドキュメントがIETFに提出されている。

1つ目は概要であり、WebTransportのトランスポートが持つ機能要件について書かれている。

例えば、データ通信としてストリーム方式・データグラム方式を持つ(パケットのデータ境界をアプリケーション側で維持するか)などである。

その他にも追加の機能として、トランスポートのストリームの独立性、Partial reliability、コネクションプール (1つのコネクションを再利用し輻輳制御を行える)、Connection mobility (IPが変わってもコネクションが維持可能)といった項目だしを行っている。

2つ目と3つ目はそれぞれ、WebTransportをHTTP/3、QUIC上で行えるようにする仕様を定義している。特にHTTP/3ではサーバからストリームを開始できるうようにWebTransport用のストリームを定義している他、追加のフレームも定義している。

(詳細は機会があればまた今度)

リンク

vせんせいも、WebTransportついて書かれております
medium.com

QUICの暗号化と鍵の導出について

QUIC, HTTP/3 関連記事


HTTP/3というかQUICの通信がどのように暗号化されているのか勉強がてら軽くまとめる。(執筆時点でQUIC-TLS Draft 19)

QUICでは、通信の多くが暗号化されています。アプリケーションデータはもちろんのこと、ACKや切断といった制御情報も暗号化されます。さらにパケット番号やフラグが含まれるQUICパケットのヘッダ部分も暗号化されています。

これらの通信の保護がどのように行われているか見ていきます。


先にQUICの概要についてざっとここらへんを見ていただけると良いかと思います。
asnokaze.hatenablog.com

目次

QUICのハンドシェイク

まずは、QUICのハンドシェイクを見ていきます。

TLS1.3のメッセージを流用しており、QUICの上でTLS1.3のメッセージをやりとりしています。
f:id:ASnoKaze:20190421222513p:plain
(引用 QUIC Security)

  • コネクションを開始するクライアントは、InitialパケットにCRYPTOフレームを格納し、ClientHelloのメッセージを送信します。(これはInitial Keysで暗号化されます)
  • もし、0-RTTでEarly Dataを送る場合は送信します。(これは、Early Data (0-RTT) Keysで暗号化されます)
  • サーバはClientHelloに対してInitialパケットにCRYPTOフレームを格納し、ServerHelloのメッセージを送信します。(これはInitial Keysで暗号化されます9
  • ServerHelloが送信できれば、Handshake Keysが導出できるので、サーバはHandshakeパケットにCRYPTOフレームを格納し、TLSハンドシェイクの残りを送信します(EncryptedExtensions, Certificate, CertificateVerify, Finished)。(これは、Handshake Keysで暗号化されます)
  • クライアントがHandshakeパケットを受け取ると、同じくFinishを送るためにHandshakeパケットにCRYPTOフレームを格納し送信します。

こうしてアプリケーションデータを暗号化するための、Application Data (1-RTT) Keysが導出できアプリケーションデータが送受信できます。

QUICでは、下記の4つの鍵が登場します。その鍵によって各パケットのペイロードが保護されます。上記図では、枠線の色ごとに使用する鍵が対応しています。

  • Initial Keys
  • Early Data (0-RTT) Keys
  • Handshake Keys
  • Application Data (1-RTT) Keys


TLS_AES_128_CCM_8_SHA256を除いてTLS1.3で定義される暗号スイートが利用できます。この暗号スイートを用いて暗号化及び(ハッシュ関数を用いて)鍵の導出が行われます

ショートパケットとロングパケット

パケットのペイロードの暗号化に先立ち、QUICパケットに関して簡単に復習します。

ハンドシェイク中のQUICパケットはすべてロングパケットです。アプリケーションデータはショートパケットで送信されます。

ハンドシェイク中に登場したようにロングパケットとしては、Initialパケット、Handshakeパケット、0-RTTパケットなどがあります。また、紹介しませんがRetryパケットといったものもあります。それぞれロングパケットヘッダ領域を持ちますが、それ以外はパケットごと固有になります。

例えば、Handshakeパケットは下記のようになります。
f:id:ASnoKaze:20190422101405p:plain

ペイロード領域に、TLSメッセージを含むCRYPTOフレームや、Ack情報を格納するACKフレームなどが含まれます。


アプリケーションデータやコネクションの制御情報を含むショートパケットは以下のようになっています。
f:id:ASnoKaze:20190422101518p:plain

ロングパケットに比べ一部の領域が省略されていることが分かります。

鍵の導出

Initial Keys

ClientHello, SeverHelloを運ぶInitialパケットを保護するInitial Keysは特殊であり、仕様に定義されるinitial_saltと送信先コネクションIDから導出されます。

具体的には下記の通りに、client_initial_secret とserver_initial_secret が導出されます。

   initial_salt = 0xef4fb0abb47470c41befcf8031334fae485e09a0
   initial_secret = HKDF-Extract(initial_salt,
                                 client_dst_connection_id)

   client_initial_secret = HKDF-Expand-Label(initial_secret,
                                             "client in", "",
                                             Hash.length)
   server_initial_secret = HKDF-Expand-Label(initial_secret,
                                             "server in", "",
                                             Hash.length)

saltはdraftバージョンで固有。今後変わる可能性があります。つまり、対応しているdraftバージョンでないと正しく復号できません。実装は、対応してない仕様を処理しようとして不具合を起こすことがありません。

少々古いですが下記に書いたとおりです。
asnokaze.hatenablog.com

そのほかの鍵の導出

それ以外の Early Data (0-RTT) Keys, Handshake Keys, Application Data (1-RTT) Keysは、TLS1.3の手順で導出されたSecretよりさらにそこから導出されます。

QUICのハンドシェイクではTLS1.3のメッセージをやり取りしています。TLS1.3の鍵導出は「RFC8446 7.1. Key Schedule」に書かれているとおりです。

下記はQUICにおける鍵スケジュールです。黄色いのはTLS1.3と同じですが、導出されたSecretからさらにQUICで使うSecretが導出されています。それが青い部分です。(図は、それぞれHKDF-ExtractとHKDF-Expand-Label)

f:id:ASnoKaze:20190421224549p:plain
(引用: QUIC Key Schedule)

QUICでは下記のそれぞれの鍵として

  • Early Data (0-RTT) Keys
  • Handshake Keys
  • Application Data (1-RTT) Keys

下記の秘密地をTLSのSecretより導出します

  • AEAD key (Label: quic key)
  • IV (Label: quic iv)
  • header protection key (Label: quic hp)

Application Data (1-RTT) Keysのみ、導出したSecretはKey Updateによって更にアップデートされていきます。

パケット保護

ペイロードの保護

各QUICパケットのペイロードは下記のように暗号化されます。

f:id:ASnoKaze:20190421225717p:plain
(引用 QUIC Security)

送信するパケットのパケット番号とIVの排他的論理和演算をとってNONCEとします。暗号化するパケットペイロードと、暗号化はしないが改ざんさてないことを確認するAADとしてパケットヘッダを入力します。あわせてNONCEと導出した鍵を入力します。

そうしてProtected Payloadを得ます。

復号する場合は、同様に求めたNONCE、鍵、暗号文を入力し平文を得ます。(実際には後述のパケットヘッダの復号を先に実施する必要があります。)

パケットヘッダの保護 (Header Protection)

QUICではペイロードのみならず、ロングパケット、ショートパケットともにケットヘッダの一部も保護されます。具体的にはパケット番号や鍵フェースなどです。

ヘッダパケットは下記のように、Protected Payloadより導出したMaskで保護されます。
f:id:ASnoKaze:20190421230951p:plain
(引用 QUIC Security)

  • Protected Payloadからサンプリングしたデータを、先に導出したHeader Protecion用の鍵でAES-ECB暗号化する形でMaskを計算します。
  • 得られたMaskを使って、ヘッダのフラグ部分とパケット番号部分の排他的論理和を取ります。

(サンプリングする箇所(サンプリングオフセット)はコネクションID長などから決定されます。)

こうしてヘッダ部分も保護されます。

復号する場合は、同様にProtected PayloadからMaskを取得しヘッダ部分を復元します。こうしてやっと、ペイロード部分の復号が可能になります。

Key Update

Key UpdateはTLS1.3とは異なり、パケットヘッダのKey Phaseビット(1bit)をトグルすることで、鍵のアップデートをピアに通知します。

しかし、この仕様は現在議論中で、新しくKEY READY bitを導入することも検討されています。

github.com

その他

実際にはパケットの順番などが入れ替わるため、再送処理や、それに伴う鍵の保持期間など細かい話がたくさんあります。。。

難しい。

この記事を書くにあたり大変参考になりました

ありがとうございます。