セキュリティの報告先を記述する、security.txtの提案仕様 (RFC9116)

Web internet-draft

Webサイトのセキュリティリスクを発見したものの、連絡先が適切に公開されていないがために、結局報告されず脆弱性が放置されるケースがあるようだ(国内だと、IPA脆弱性関連情報の届出受付もあるが)

発見者が脆弱性等の報告を出来るような情報を、Web作成者が提供できるようにする仕様がIETFに提出されている。

この「A Method for Web Security Policies」という提案仕様では、security.txtをドメイン直下のURLに配置し、連絡先などを記述するようになっている。

security.txt

security.txtは例えば以下のとおりである

# Our security address

Contact: security@example.com
Contact: +1-201-555-0123
Contact: https://example.com/security
Encryption: https://example.com/pgp-key.txt
Disclosure: Full
  • #: コメント行
  • Contact: 連絡先。メールアドレス・電話番号・URLが記述できる
  • Encryption: 暗号化用の鍵
  • Disclosure: 問題の対応後の、受け付けた報告の開示ポリシー。Full, Partial, Noneのいずれか。

QUICにおける信頼性のないストリームの提案仕様

HTTP QUIC internet-draft

20180923追記

QUICの信頼性のないデータグラム拡張(MESSAGEフレーム/Datagramフレーム)
https://asnokaze.hatenablog.com/entry/2018/09/23/012519

別の拡張仕様案が議論されています

QUICはUDPを使用しますが、内部的にストリームという信頼性のある通信単位をもちます。ストリーム上では正しい順序での配送が保証され、パケットロスしたデータも回復されます。

そのようなQUICに対して、信頼性のないストリーム、つまりパケットロスしても回復しないようなストリームの検討を行うInternet-Draftが出ている。また、合わせてその信頼性のないストリームを用いてHTTPボディを送るための仕様も提出されている。

ぞれぞれ下記の通りである

これらによって、HTTPヘッダは確実に届けるが、HTTPボディはロスしても良いというHTTPが実現できるのは面白い点である。

現状の標準化動向としては、QUICの仕様に取り込まれるかは分からないが(個人的には険しいと思う)

面白そうなので簡単に読む

Considerations for Unreliable Streams in QUIC

信頼性のないストリームに関する考慮事項と要件について書かれている。ちなみに、この仕様はQUICのdraft-04を参照している点にも注意である。

  • コネクション確立時に、この仕様に対応していることを示すaccept_unreliable_stream_framesトランスポートパラメータを用いてネゴシーエションする
  • 信頼性のないストリームをオープンする際に'R' (RELIABLE)フラグを立てる
  • ゾンビストリームを防ぐため、ストリームのクローズ(FIN)はロスした場合は再送される
  • 信頼性のないストリームは、輻輳制御およびフロー制御をうける
  • アプリケーションは、任意の再送戦略を取れる(再送しても良い)

Unreliable Transmission Extension for HTTP/2 over QUIC

メディアなどの配信のために、HTTPボディの送信に信頼性のないQUICストリームを利用するための仕様。基本的には上記の「Unreliable Streams in QUIC」の仕組みを用いる。

  • クライアントから「Transport-Response-Reliability: unreliable」ヘッダを用いることで、レスポンスに信頼性のないストリームの利用を要求できる
  • 「Transport-Response-Reliability: unreliable-after DATE」で時間を指定することで、指定時間経過後は再送しないことも要求できる
  • HTTPヘッダに関しては信頼性のあるストリームで送信されるなければならない(draft-ietf-quic-http-04, 05に言及)

TLS record_size_limit 拡張の提案

TLS internet-draft

IoTデバイスなどリソースが制限されている端末でTLS通信を行うのには課題がある。特に送られてきたレコードを復号するのにはそれを計算する十分なメモリが必要になる。

リソースが制限されている端末でも問題なく復号処理が出来るように、相手に受信したいレコードのサイズを伝えられるようにするrecord_size_limit拡張の仕様が提案されている。

仕様は「Record Size Limit Extension for Transport Layer Security」であり、MozillaのMartin Thomsonによって提案されている。この提案はすでにWGドラフトになっている。

この仕様によって、max_fragment_length 拡張は廃止される。

max_fragment_length拡張 の課題

似たように最大フラグメントサイズをネゴシエーションする拡張としてmax_fragment_length がある。しかし幾つかの課題がある

  • サイズが対象であり、クライアント・サーバ両方が送信するサイズが一緒である
  • クライアントからの提案に対して、サーバはそれより低い値を提案できない(サーバの方のリソースが制限されている場合に問題)
  • 最大レコードサイズは2^14なのにたいし、2^12までしか指定できない

record_size_limit拡張

現在、record_size_limit拡張の拡張コードはTBDになっているが、値はuint16で指定することになる。

uint16 RecordSizeLimit;

このrecord_size_limit拡張では

  • 制限は平文サイズに対して適応される(パディングなどは含まない)
  • 送信相手にのみ適応される。自信はそれ以上のサイズを送信して良い。
  • サーバが制限しようとすることもあるので、クライアント側はサイズを制限しなくてもrecord_size_limit拡張を送信スべき
  • 64以下のサイズを送っていはいけない

record_size_limit拡張によってmax_fragment_length拡張はとって代わります。record_size_limit拡張をサポートするサーバは、record_size_limit拡張とmax_fragment_length拡張がClientHello似合った場合無視しなければなりません。

W3CにおけるWeb Lifecycleの議論 (Page Lifecycle API)

Web 雑 w3c

20180523 追記

Page Lifecycle API等とも呼ばれているようです。
github.com

下記内容は古く一部ことなっています

W3CでWebPerf Web Performanceで、「Web Lifecycle」というトピックが議論に上っていた。(Agenda URL)

これは、iOSアプリやAndroidアプリのActivityのようなライフサイクルを、Webアプリケーションでも定義しようというものらしい。

まだ具体的な仕様は無いものの面白そうなので簡単に見てみる。ちょうざっくり

背景

  • 30%以上のユーザがタブを10以上開いており、現在表示しているタブのユーザ体験に影響を与えている
  • バックグラウンド(非表示のタブなど)の扱いについて明確なライフサイクルは存在しない(デスクトップとモバイルで扱いが異なる)
  • ライフサイクルやAPIがなく、アプリケーションが自身がどういう状態にあるか分からない(既にイベントはあるが一貫性がない)

提案

f:id:ASnoKaze:20170831231236p:plain
(スライドより)

  • LOADING: 読み込み状態
  • ACTIVE: 見えており、フォーカスがある状態
  • PASSIVE: 見えているがフォーカスはない状態 (例えばアプリケーションはゲームの停止などを行う)
  • BACKGROUNDED: 見えてない状態。例えばUI処理の停止される。
  • STOPPED: 見えてない状態。バックグラウンド実行の停止。
  • DISCARDED: メモリ再利用のためにバックグラウンドタブの廃棄。
  • TERMINATED: ユーザによってタブが閉じられた。

図の通り、BACKGROUNDEDやSTOPPEDからもタブが選択されれば再度、ACTIVEな状態に遷移する。

各状態遷移時にイベントが発火するためアプリケーション側は現在の状態を検知できるようになっている。

この状態遷移によって

  • 各状態のコールバックを用意し、アプリケーションがデータの保存やレポートを送れるようになる
  • アプリケーションはバックグラウンドで行いたい作業を宣言できる(Audio, Network Upload, Updating tab titleなど)
  • 適切なバッググラウンド処理が可能(ServiceWorkerの利用、必要なものにレンダラのリソース配分)
  • アプリケーションに依存するが、リソースの制限によってシステムによってアプリケーションを停止・終了できる

課題

まだまだ議論が始まったばかりだが、幾つかの課題が挙げられている

  • STOP遷移時のコールバック(onStop)の制限事項。ネットワーク利用の制限などどうするか
  • バックグラウンド実行時の処理・レンダリングをどうするか(WebUSB, Updating title and favicon, Notifications)
  • 同一ドメインで複数タブを開いた時に、タブを超えてデータが共有される。STOP時に壊れてしまう
  • ダイアログの表示を保存するか

ただしCurrent Workがあるようなので、Googleとしてはそういう動きがあるんだと思われる

Chrome62から、http://でのフォームに入力すると警告が出るようになる

雑

2017/10/18更新 Chrome 62がリリースされましたが。徐々に適応されていくようです。


Chrome 52(今年1月リリース)において、パスワードの入力フォームがあるとアドレスバーに警告が出るようになったのはニュースサイトでも多くとりあえげられたのでご存じの方も多いと思います。
www.itmedia.co.jp


上記内容のGoogleからのアナウンスにおいて、Chrome62(今年10月リリース予定)で対応を強めることもアナウンスされています。
security.googleblog.com


Chrome62より、http://のページで、 type="text"などの入力フォームに文字を打つとアドレスバーに警告が出るようになるもようです。

フォーム入力時の警告

Chrome Canaryでデータ入力時の警告を確認できるようになりました
f:id:ASnoKaze:20170818122057g:plain


この機能は、Chrome Canaryでchrome://flagsのより、
「Mark non-secure origins as non-secure」を「warn on http while in incognito mode or after editing forms」にすると機能するようになります。
(現状、betaだと有効にしても警告が出ないような気がします)
f:id:ASnoKaze:20170818122423p:plain


現状、文字を入力するinput typeでのみ警告が出るようで、fileやチェックボックスでは警告は出ないようです。

GoogleのQUICの論文が知見の塊だった

雑 QUIC

20181107追記 QUICプロトコルについての概要は別途記事を書きました
asnokaze.hatenablog.com

概要

ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。

この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。

すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。

QUICはGoogle Searchのレイテンシをデスクトップユーザでは8%, モバイルユーザでは3%削減しており。Youtubeのリバッファリングをデスクトップで18%、モバイルで15%削減したようである。

QUICの設計、機能の説明とデプロイ結果からパフォーマンスについて詳細に書かれている。

特に7章の知見については面白かったので簡単に読んだことをまとめた。

雑であしからず

全体構成

  • 1.INTRODUCTION
  • 2.MOTIVATION: WHY QUIC?
  • 3.QUIC DESIGN AND IMPLEMENTATION
  • 4.EXPERIMENTATION FRAMEWORK
  • 5.INTERNET-SCALE DEPLOYMENT
  • 6.QUIC PERFORMANCE
  • 7.EXPERIMENTS AND EXPERIENCES
  • 8.RELATED WORK

個人的に面白いと思ったのは、3章、6章、7章である。

3.QUIC DESIGN AND IMPLEMENTATION

3章の「QUIC DESIGN AND IMPLEMENTATION」はQUICの基本的な機能とその仕組について書かれている。

  • Connection Establishment
  • Stream Multiplexing
  • Authentication and Encryption
  • Loss Recovery
  • Flow Control
  • Congestion Control
  • NAT Rebinding and Connection Migration
  • QUIC Discovery for HTTPS

6.QUIC PERFORMANCE

6章の「QUIC PERFORMANCE」が、今回のメインであるパフォーマンス測定に関する章である。
TLS/TCPとQUICのハンドシェイク遅延の比較、Google Search及びYoutubeのレイテンシの比較、South Korea・USA・India地域ごとの性能比較、サーバ側のCPU使用率の話

7.EXPERIMENTS AND EXPERIENCES

7章の「EXPERIMENTS AND EXPERIENCES」は直接QUICと関係ないが実験より得られた知見が書かれている。
個人的には非常に面白かったので、幾つかピックアップ。FECについては、以前書いたので割愛。

asnokaze.hatenablog.com

Packet Size Considerations

プロジェクトの初期に、UDPパケットの最大サイズを決定するための調査が行われていました。
2014年にネットワーク上のエコーサーバに向けて、UDPペイロードを1200バイトから1500バイトまで5バイトおきに接続性のテストを行っていたようです。

f:id:ASnoKaze:20170813015054p:plain
(引用: 7.1節 図12)

接続の失敗は、1450バイト後に急増しておりQUICでは1350バイトが選択された。

UDP Blockage and Throttling

UDPの疎通性に関して、2016年にビデオ再生に関するメトリックスで

  • 95.3% が問題なく使用できた
  • 4%が、UDPがブロックされるか経路のMTUが小さすぎて使用できなかった。これは企業内のファイアウォールケースが多いようです。
  • 残りの0.3はUDPのトラフィックが制限されており、トラフィックが高い場合はパケット損失率が大幅に上がるようです。ASレベルの制限は減少傾向にあるようです。
User-space Development

QUICはユーザスペースで処理されます。このメリットについて書かれています。

ユーザランドで開発することで、カーネルでは制限されているような機能でもロギングが可能で様々なバグの発見に役立ったようです。

Cubicをユーザランドで再実装することによってLinuxにあった古くからあったcubicの実装にバグを見つけたのはニュースにもなりました。
news.mynavi.jp

また、カーネルに組み込むよりもユーザに早く更新を届ける事が出来た旨も書かれています。これはセキュリティプロトコルにとっては非常に重要なことです。

Experiences with Middleboxes

ファイアウォールといった中間装置の振る舞いについて

QUICでは殆どのデータを暗号化していますが、一部は暗号化されていません。2016年10月にその暗号化されてない部分の1bitの変更を加えたところ、一部のファイアウォールが混乱し最初のパケットのみを疎通させその後はブロックするような振る舞いをするようになりました。その場合、TCPに正常にフォールバックされません。

フラグ部分をもとに戻すことで対応するとともに、ファイアウォールベンダーを特定し連絡を取りフラグの分類について更新することで問題は解決されたようです。

その時はベンダーを特定し対応できたが、インターネット上で特定のビットがファイアウォールにどのように影響するか答えることはできません。

これはファイアウォールの影響を避けるために殆どの領域を暗号化するQUICの設計の前提を強めた形になります。

ジオロケーションを要求・送信する HTTP Geolocationヘッダの提案仕様

HTTP internet-draft

GoogleのLuis Barguno Jane氏より、HTTPヘッダでジオロケーション情報の要求・送信を可能にする「Geolocation Header for HTTP over a Secure Context」という仕様が出ています。

背景

ユーザエージェントにおいてジオロケーションの取得は「Geolocation API」で取得可能でした。

しかし、この方法はHTMLを読み込んで、JavaScriptを実行して、サーバに送信する流れになります。サーバは、最初に読み込まれるHTMLを生成時はどうしても位置情報が使えないという事情があります。

また、スマートでバイスやIoT機器でJavaScriptの実行をサポートしてない環境においては、ジオロケーションの要求・送信に仕様はないのが現状です。

Secure Contexts下でジオロケーションの要求・送信が出来る仕組みを定義したのがこの仕様です。

HTTPレスポンスでGeolocation-Requestヘッダを受け取ったクライアントは、次回から指定されたPathにアクセスした時はGeolocationヘッダでジオロケーションを送信するようになります。

example

Geolocation-Requestヘッダ

サーバから、HTTPレスポンスにおいてジオロケーションを要求するGeolocation-Requestヘッダ

Geolocation-Request: Path="/localService"; Type=IfAlreadyGranted;
       Expires=Thu, 18 Dec 2017 12:00:00 UTC

(#本当は1行)

  • Path: ジオロケーションを送信するスコープとなるPath
  • Type:
    • IfAlreadyGranted: 既にそのオリジンにおいて、ジオロケーションの取得が許可されていた場合のみジオロケーションを送信する
    • MayPrompt: ジオロケーション取得のパーミッション要求プロンプトを表示してもよい(ユーザエージェント次第)
  • Expires: 有効期限
Geolocationヘッダ

クライアントから、HTTPリクエストにおいてジオロケーションを送信するGeolocationヘッダ

Geolocation: Position=[47.368684, 8.535741, 345]; Accuracy=10;
         Timestamp=1495804846156; AltitudeAccuracy=20; Speed=1.5;
         Heading=27.53;

(#本当は1行)

  • Position:RFC7946 GeoJSON形式の位置情報 (必須)
  • Accuracy: メートル単位の精度 (必須)
  • Timestamp: 取得時のタイムスタンプ (必須)
  • AltitudeAccuracy: メートル単位の高度精度
  • Speed: 速度(m/sec)
  • Heading: 方位(0～360)