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のセキュリティに関する議論は根強く続けられていますが、すぐには解決できなく難しいですね。。。

ギガの減り方など、ユーザのデータプランを考慮して最適化するGoogleサービス

モバイル通信事業者が、ユーザのギガの残量やデータプランなどをGoogleと共有する、「Mobile Data Plan Sharing API」というものがあるらしい。

モバイル通信事業者に提供されているAPIであり、おそらく一般サービス運営者は利用することは出来ない。

GoogleではこのAPIを通してユーザのデータプランを共有し、様々な最適化を行っているようである。

  • ユーザのデータ通信残量を考慮して通信の最適化を行う
  • 通信のオフピークに通信を行う

この連携を行うために、モバイル通信事業者が、DPAと呼ばれるデータプランをGoogleのサーバと共有するサービスや、PlanGloupIDを生成するPGID Endpointと呼ばれる機能を実装する必要がある。

すでに、インドの3通信事業者とYoutubeで非ピーク時にデータ通信をさせる実験済みらしい(Web5Gの文章より)。(YoutubeのSmart Offline

もちろん、サービスやクライアントがどのように最適するかは実装依存である

Mobile Data Plan Sharing API

f:id:ASnoKaze:20180404004442p:plain

共有されるデータは、下記のようなデータで
byteBalanceとしてデータ通信残量や、その他データプランのカテゴリが共有される。

もちろん例の他にも、時間制限の場合は時間残量、最高トラフィック量や、制限を超えた場合のポリシーなどが共有される。
詳しくはレファレンスに記載されている。

{
  "planGroupId": "abcdef",
  "planGroup": {
    "dataPlans": [
      {
        "planName": "ACME Red",
        "planId": "turbulent1",
        "expirationTime": "2020-02-03T04:05:06Z",
        "planModules": [
          {
            "byteBalance": {
              "quotaBytes": "1000000000",
              "remainingBytes": "9876543210"
            },
            "trafficCategories": [
              "GENERIC"
            ],
            "expirationTime": "2020-02-03T04:05:06Z"
          }
        ]
      }
    ],
    "responseStaleTime": "2018-03-04T05:06:07Z"
  }
}

その他

正直自分でためせなさそうだし、資料も多くないので、、、
詳しい人がいたら教えてほしい。

HTTP Server Pushのセマンティクス拡張する、HTTP Server *ush の提案仕様

4/1 に「HTTP Server *ush」という提案仕様が、IETFに提出されています。

4/1にです。

HTTP Server *ush

「HTTP Server Push」の音節構造は非常に舌に馴染むものです。HTTP Server Pushの成功の一つの理由でしょう。

そこで、同じ音節構造を持つ様々な「HTTP Server *ush」を定義しようというのが、この提案です。

このドキュメントでは、HTTP/2でサーバプッシュを利用するのに使用された「SETTINGS_ENABLE_PUSH 」と同様に「SETTINGS_ENABLE_*USH 」というSETTINGSパラメータを定義します。

Server Cush

Server Cushはより豪華なHTTP Server Pushです。
SETTINGS_ENABLE_CUSHで有効にすることが出来ます。

Server Dush

Server Dushはより激しいhTTP Server Pushです。
SETTINGS_ENABLE_DUSHで有効にすることが出来ます。

Server Gush

Server Gushは突然のオーバーフローをサポートするHTTP Server Pushです。
SETTINGS_ENABLE_GUSHで有効にすることが出来ます。

Server Hush

Server Hushはより丁寧なHTTP Server Pushです。
SETTINGS_ENABLE_HUSHで有効にすることが出来ます。

Server Kush

Server Kushは適法性が地域によって異なるHTTP Server Pushです。
SETTINGS_ENABLE_KUSHで有効にすることが出来ます。

Server Lush

Server Lushは植物に関係するリソースのためのHTTP Server Pushです。
SETTINGS_ENABLE_LUSHで有効にすることが出来ます。

Server Mush

Mushにはネガティブな意味があります。このServer Pushは予約されており、使用できません

Server Rush

Server Rushはより迅速にプッシュできるHTTP Server Pushです。
SETTINGS_ENABLE_RUSHで有効にすることが出来ます。

Server Tush

Server Tushはサーバがプッシュプロミスに時間がかかりすぎると不賛成するHTTP Server Pushです。
SETTINGS_ENABLE_TUSHで有効にすることが出来ます。

Server Blush

Server Tushはクライアントが望まないプッシュをしてしまうとサーバは恥ずかしく感じるHTTP Server Pushです。
SETTINGS_ENABLE_BLUSHで有効にすることが出来ます。

Server Flush

Server Flushは北半球と南半球のコリオリ効果を考慮したServer HTTP Server Pushです。
SETTINGS_ENABLE_FLUSHで有効にすることが出来ます。

Server Plush

Server Cushと同義です

Server Slush

Server Slushは過度に感情的なServer HTTP Server Pushです。
SETTINGS_ENABLE_SLUSHで有効にすることが出来ます。

Server Smush

Server SmushはServer GushとServer Slushの論理和です
SETTINGS_ENABLE_SMUSHで有効にすることが出来ます。

QUICの現状確認をしたい 2018/3 (QPACK, Spin Bit, Invariants)

QUICの現状確認をしたい。
(あまり追えてないのでつらい)

先月分
asnokaze.hatenablog.com

目次

仕様の状況

3月頭に4つのコアドキュメントのdraft-10が出ている。

あまり差分は大きくないが、トランスポートでは前回分で書いたコネクションマイグレーション時に使うPATH_CHALLENGE、PATH_RESPONSEフレームが追加されたほか、ACK周りの再送するフレームに関する情報が追記された。

TLS利用の仕様では、QHKDF-Expandに関する記述が増えている。

おそらく、もうそろそろ draft-11 が出ると思われる。

また、その他の仕様では、QUICのHTTPヘッダ圧縮方式については長らく議論されていたが、QCRAMと呼ばれていた仕様がWG Draftとなっている。なお、非常に紛らわしいところであるが、QCRAMはQPACKに改名された。

QPACKについては以前書いたが、少なからずの変更が入っている。
asnokaze.hatenablog.com

また、将来のQUICバージョンアップデートをデプロイしやすくするための、invariantsと呼ばれる仕様もdraft-01が出ている。WG Last Callとなっている。

asnokaze.hatenablog.com

マイルストーンの変更

WGのマイルストーンに、Header Compression for HTTP over QUICが追加されたほか。

以前、チェアから意見が出たとおり、マルチパス QUICに関するマイルストーンは削除されました。

QUIC V1では、マルチパスQUICは対応されません。
QUIC V1では、マルチパスQUICは対応されません。

IETF101

3/17 ~ 3/23 にかけて、IETF 101がロンドンで開催された。
QUICに関しては、QUIC WGのセッションが2つ開催されたほか、ハッカソンで実装を持ち寄っての相互接続テストも実施された。

下記の発表が行われました

  • Hackathon Update
  • EDITORS UPDATE
  • QUIC DTLS and Stream 0
  • Invariants
  • ECN
  • Spin Bit Proposal

議事録及び発表資料はGithubで公開されている
wg-materials/ietf101 at master · quicwg/wg-materials · GitHub

相互接続性テスト

4th Implementation Draftで、相互接続テストが実施された。これは、 draft-09 と TLS1.3 draft-23の実装です。

f:id:ASnoKaze:20180331005345p:plain

  • V: Version Negotiation
  • H: Handshake
  • D: Stream Data
  • C: Connection Close
  • R: Resumption
  • Z: 0-RTT
  • S: Stateless Retry

次回のinteropは、5月にリモートでの開催が予定されている。
5th Implementation Draftとして、draft-11 と TLS1.3 draft-28で相互接続テストが実施される。

Spin Bit

発表資料: wg-materials/spin-101.pdf at master · quicwg/wg-materials · GitHub

以前書いたSpin BitをQUICとして正式に採用するかという議論が白熱しました。
asnokaze.hatenablog.com

会場参加の実装者の賛同はあまり得られておりませんでしたが、下記の通り hum を取ることになりました。

  • (a) QUIC V1にSpin Bitを入れない
  • (b) 予約bitを確保し、拡張仕様として別ドキュメントで定義する
  • (c) まだわからない

結果としては、(b)となったようです。
後日MLでチェアのmnot氏が下記のようにまとめています。
Spin Bit -- a Path Forward

QUIC DTLS and Stream 0

発表資料:wg-materials/Stream0-EKR.pdf at master · quicwg/wg-materials · GitHub

以前書いた通り、EKR氏よりQUIC over DTLSの提案がありました。
asnokaze.hatenablog.com

この話を発端に、QUICのレイヤリングとストリーム0に関しては専門のチームが結成され、検討が進められるようです。

下記のメール参照
Stream 0 Design Team

A First Look at QUIC in the Wild

発表資料:https://datatracker.ietf.org/meeting/101/materials/slides-101-maprg-a-first-look-at-quic-in-the-wild-00

maprg では、QUICのインターネットでの利用状況に関する発表がありました。ヨーロッパのTier-1 ISPでの、QUIC, HTTPSトラフィック量比較などの調査結果が報告されています

InvariantsのWGLC

Version-Independent Properties of QUICがWG Last Callとなっている。

チェアの「Working Group Last Call: QUIC Invariants」に詳しく書いてあるが、これは QUICの不変部分がより高いレベルで変更されないと信頼できるようにするためである。WGLC後すぐに先のステップに進むのではなく、そのタイミングで停滞させるようである。

なお、強い理由があればInvariantsの仕様を変更する事ももちろんある。

このような戦略的なWGLCは面白いなと思いました。

Symmetric connection IDs

Draft-11で入る、大きな変更点があります。
github.com

Coneection-IDが、Source Connection IDとDestination Connection IDに変更され、さらに可変長となりました。これによって、クライアントのパケット処理がよりシンプルになるようです。

この変更によって、Long Headerは下記の通りになります
f:id:ASnoKaze:20180331013127p:plain

Short Headerは下記の通りになります。Short HeaderはDestination Connection IDだけになります。Lengthが無いのは、その長さがお互いにわかっているため、Lengthはありません。
f:id:ASnoKaze:20180331013233p:plain

あまり自分もちゃんと理解できないので、詳しい人がいれば補足してほしい...

ChromeがWebSockets over HTTP/2に対応したので試す

以前書いたとおり、Websockets over HTTP/2の仕様である「Bootstrapping WebSockets with HTTP/2」が現在標準化が進められている。
asnokaze.hatenablog.com

これにより、複数のWebsocket通信が1つのTCPコネクションに束ねられる。

一つのページで複数WebSocketを使っていたり、複数タブを開いて各ページでWebSocketを利用しているとどうしてもコネクションの本数が多くなってしまう。様々なメリットがあるが、コネクションの数がへらせるのはサーバ側でも嬉しい部分がある。

もちろんひとつに束ねられたWebSocketをばらして処理をする必要があり、サーバやProxy側の実装が整う必要はある。

さて、このWebsockets over HTTP/2にChrome Canaryが対応したので実際に試してみる。

WebSockets over HTTP/2

「WebSockets over HTTP/2」の概要に簡単に触れる

WebSockets over HTTP/2を利用するにはサーバ側からSETTINGSフレームで「ENABLE_CONNECT_PROTOCOL = 1」を送る必要がある。そのため、既存のサーバに対してブラウザが勝手にHTTP/2でWebScoket通信を試みるようなことはない。

具体的な通信手順は以前書いた時より仕様が進んでおり、HEADERSフレームを使用するようになっている。
f:id:ASnoKaze:20180310012152p:plain:w400

Chromeで Websockets over HTTP/2を有効にする

現状はChrome Canaryで有効にすることが出来る。
起動オプションに "--enable-websocket-over-http2"を与えて起動すると、Websockets over HTTP/2が有効になる。

Chromeの実行パスがわからない場合は、URLバーにchrome://version/と打ち、コマンドラインの項目から確認できる

試す

ざっくり適当に、モックサーバを用意した。

f:id:ASnoKaze:20180310014954p:plain

HTTP/2で接続しにいって、WebSocketのonopenイベントが発火するところまで確認した。
(地味な動作確認画面だ...)