hostname

report-uri 指令 (HTTP)

仕様書

意味

[4] 利用者エージェントPin Validation の失敗を報告するべきことと、 その報告先 URL を指定するものです >>1

構文

[36] 値は、 URL です。

[35] RFC では構文はなぜか明記されていません。

[11] 指定するホストが本応答ホストと一致している必要はありません >>1

[37] 相対URLが指定された時の基底URLや、 URL として正しくない文字列が指定された時の解釈は不明です。

文脈

[2] PKP ヘッダーに指定できます。

[3] 省略可能です >>1

処理

[6] URL が指定されている場合で Pin Validation に失敗した時は、 報告を指定された URL に送信するべきです >>1, >>22利用者エージェントは報告するよう最善の努力を尽くすべきですが、 例外的状況で報告できなくても構いません >>1

[12] 例えば報告先が Pinning Validation その他の証明書の検証に失敗するなら、 接続を中止しなければなりません >>1

[34] PKP の処理の項も参照。

[18] 任意の他サイトに報告を送って良いのかどうかは謎です。とはいえ同じホストに送ってもおそらく Pin Validation エラーになることは変わらないので、違うホストに送る必要があるのでしょうが...

[19] DDoS に使えそうですが、 imgscript で他のホストに要求を送らせること自体は既にできるので、新たな脅威ではなさそうです。
[39] ただし CORS なしで JSON を異なる起源POST できるのは初めてと思われます。 これを想定していない Webアプリケーションはあるかもしれません。

[43] 利用者エージェントは同じ起源に制限しても構いません >>42

[44] PKP-RO の場合は良いとして、 PKP の場合はほぼ確実に送れなくなりますが...

[5] 利用者エージェントは、指定された URL に報告を POST します >>1, >>22

[24] RFC では、「POST」と書かれているだけで、その意味はなぜか明記されていません。 要求メソッド POST により送信することを意味すると推測されます。

[7] 利用者エージェントは、指定された URL schemeTLS を使うものなら、ホストKnown Pinned Host であるなら Pinning Validation をしなければなりません >>1

[8] 利用者エージェントは、指定されたホスト既知HSTSホストなら、 HSTS を適用しなければなりません >>1

[9] リダイレクトをどう処理するべきかは不明です。
[10] 趣旨からすると HSTS 適用後に TLS を使うなら Pin Validation を行うべきと思われます (が仕様書にはそうは書いていません)。

[13] 報告先ホストが Pin Validation に失敗し、元のホストに報告するよう求めるようなループを検出し、報告をやめるべきです >>1

[14] なぜこれが MUST でなくて SHOULD なのかは謎です。無限ループに陥る実装が正当である理由など無いと思うのですが...

[15] 報告失敗時には、後から再送を試みても構いません >>1

[16] 報告送信頻度は制限するべきです >>1。 同じ報告をむやみに繰り返さないよう努力するべきです >>20

[17] 例えば同じ組の Pin に関して同じ URL に同じ報告を何度も送る必要はありません >>1

[21] PKP-RO は当該応答の処理後は検証のために情報を保持しないことになってはいますが、 報告の重複チェックのために保持することは禁止されていない (むしろ求められている) ようです。

[23] POST するデータは、次のような JSONオブジェクトです >>22

JSONオブジェクト
date-time
Pin Validation に失敗した時刻を、 RFC 3339の日時形式で表したものです >>22
hostname
Pin Validation に失敗した要求ホスト名を表す文字列です >>22
port
Pin Validation に失敗した要求ポートを表す整数です >>22
effective-expiration-date
ピン実効満期日付を、 RFC 3339の日時形式で表したものです >>22
include-subdomains
includeSubDomains 指令が指定されていたかどうかを boolean で表したものです >>22
noted-hostname
既知ピン付きホストとして記録された時のホスト名です >>22includeSubDomains が指定されていた時は hostname と異なる値になるかもしれません。
served-certificate-chain
TLSセッションの設定の時点でサーバーから提供された証明書鎖を、 各 X.509証明書.pem 形式の文字列の配列としたものです >>22
validated-certificate-chain
証明書鎖検証 (verification) の過程で利用者エージェントが構築した証明書鎖を、 各 X.509証明書.pem 形式の文字列の配列としたものです >>22。 検証の過程で複数組の証明書鎖を構築した場合は、最後のものとするべきです >>22
known-pins
既知ピン付きホストに関して記録されているピン配列です。 各ピンは、ハッシュアルゴリズム名、 =引用文字列の形にした文字列です。引用文字列は、 SPKI Fingerprintbase64 符号化したものです。 >>22

[25] 同じ名前と値の組が複数あってはなりません >>22

[33] (広義の) HTTP の一部であるにも関わらず、HTTPの日時形式ではなく RFC 3339の日時形式が採用されています。

JSON ではしばしば RFC 3339の日時形式ISO 8601の日時形式のバリエーションが使われるためでしょうか。

[27] 証明書鎖は、含まれる証明書の順序をそのまま配列内の文字列の順序とするべきと思われます。 (自明と考えられたためか、明記されていません。)

[45] 証明書鎖には、組織内で使う MITM proxy証明書のような、 外部に晒したくない情報が含まれてしまう場合もあり、注意が必要です >>42

[46] どう対処するべきなのかは不明です。

[28] known-pins の各ピンの値は、 pin-* 指令と同じ構文となっています。 値は引用文字列でなければならず、字句ではいけないようです。

[29] アルゴリズムの名前は、pin-* 指令の名前と同じものとされていることから、 大文字・小文字不区別と思われますが、明記はされていません。

[30] RFC引用文字列" が含まれることからその JSON 文字列では \ によりエスケープするか、 ' で括るかのいずれかとしなければならないとしています。例 (>>26) も ' を使っています。しかし、 JSON では ' で文字列を括ることは認められていませんから、本 RFCJSON の両方の規定を満たすためには、 ' は使えませんし、 RFC の例は正しくありません。RFC正誤表はこれを修正しています >>31

[32]RFC提案標準であり、IESG の承認を含め多くの人の目を経て出版されているはずですが、 このような初歩的かつ致命的な誤りが含まれたまま RFC として出版されるとは、 IETF の手続きは何とも杜撰なもののようです。

[26] 例えば次のようにします >>22, >>31

  {
    "date-time": "2014-04-06T13:00:50Z",
    "hostname": "www.example.com",
    "port": 443,
    "effective-expiration-date": "2014-05-01T12:40:50Z"
    "include-subdomains": false,
    "served-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\nMIIEBDCC...kVDNx\n-----END CERTIFICATE-----",
      ...
    ],
    "validated-certificate-chain": [
      "-----BEGIN CERTIFICATE-----\nMIIEBDCI...kVDNx\n-----END CERTIFICATE-----",
      ...
    ],
    "known-pins": [
      "pin-sha256=\"d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=\"",
      "pin-sha256=\"E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=\""
    ]
  }

[38] 報告は JSON なので、 MIME型 (Content-Type: ヘッダー) を application/json としなければならないものと推測されますが、 RFC には明記されていません。

[40] Referer:, Origin:, Cookie:, Accept-Language: その他のヘッダーをどう扱うべきかは不明です。

[41] Service Worker を通すべきかどうかは不明です。

メモ

[47] Deprecate 'report-uri'. Drop 'reports'. 'report-to' is the new hotness. · w3c/webappsec-csp@90528dd ( 版) <https://github.com/w3c/webappsec-csp/commit/90528ddb877c8241208f83e752a2f4cf6829e610>

[48] 'report-to' overrides 'report-uri'. Closes #51. · w3c/webappsec-csp@ab03aef ( 版) <https://github.com/w3c/webappsec-csp/commit/ab03aef0560b244f90b310d39db04e29c3cdc29f>

[49] No CSP report-uri|frame-ancestors|sandbox in meta · whatwg/html@3947072 ( 版) <https://github.com/whatwg/html/commit/39470724136a366bab4e893efd889a513d61cc3e>

[50] Pass a base URL to the URL parser for violation reporting. (mikewest著, ) <https://github.com/w3c/webappsec-csp/commit/5e4ef7a41c44a7229db10d33659a980f04494f00>

[51] Exclude fragments from reported URLs. (mikewest著, ) <https://github.com/w3c/webappsec-csp/commit/c60db267c4f295d50652a6ca24d825059f83390e>

[52] Note that violation reports are attacker controlled. (mikewest著, ) <https://github.com/w3c/webappsec-csp/commit/6b9fdc97d9a8acfe00b62f5000d83f55ee13b5e6>