RFC 8164

RFC 8164

[13] Opportunistic Security for HTTP/2 は、 http: URL によって表され、本来なら素のHTTPで行われるべき HTTP アクセスを、 HTTPS (HTTP/2 over TLS) 転送路を使って行うものです。

[14] プロトコルとしては同じ HTTPS であっても、 https: URL によって表される HTTPS アクセスとは、異なるものです。本手法を使っても、 (https: URL によって表される HTTPS アクセスで防げる) すべての攻撃を防げるわけではありません。

代替

[18] HTTPS を使うべきです。

仕様書

プロトコル

[29] 本機能は HTTP代替サービスを使っています。

一般的な事項は代替サービス参照。

代替サービス広告

[19] 起源サーバーは、 プロトコルの識別子を代替サービスとして広告します。 ここで、プロトコルは、 TLS を使うもの (例えば h2) とします。 プロトコルは、資源scheme を明示的に示すものでなければなりません>>12

[20] HTTP/1.1要求対象絶対URLを指定することを認めてはいますが、 (プロキシサーバーではなく) 起源サーバーに対して指定することは認めていませんので、 該当しません >>12
[27] 代替サービスのプロトコルの識別子は、 ALPN の識別子です。 原則として TLS 上のプロトコルを表していますが、 h2c のようにそうでないものもあり、ここでの条件に合致しないことになります。 ftp のように URL を指定できないプロトコルも、 scheme を明示するとの条件に合致しません。

[21] クライアントは、そのような代替サービス広告を受信したら、 以後その起源への要求を指定された代替サービス経由で送信して構いません。 >>12

[23] クライアントは、代替サービスの接続の準備が完了するまで、 要求の送信を遅延させることができます。その場合、接続に失敗したら、 通常の平文の接続で送信することになります。 >>12

[28] 代替サービスの接続の失敗は downgrade attack の可能性もあり、注意するべきことが代替サービスの仕様で注意喚起されています。 代替サービス参照。

[22] クライアントは、まず OPTIONS 要求のような繊細な情報が少ない要求を送信して、 代替サービスが無いか確認することもできます。 >>12

[24] クライアントは、既知の代替サービス満期が近い時、 OPTIONS 要求のようなものを予め送信しておき、 代替サービス情報を更新することもできます。 >>12


[51] 代替サービス広告素のHTTPで送受信されますから、改竄の可能性があります。 例えば Alt-Svc: ヘッダーを削除することで、 downgrade attack が可能です >>12

TLS ハンドシェイク

[25] クライアント証明書は、意味を持ちません。 クライアントは、 クライアント証明書を指定してはなりません>>12

[26] サーバーは、同じポートhttps: も提供する場合に、 証明書要求することができます。 しかし、クライアント証明書を提供しない場合にも、 ハンドシェイク中断 (abort) してはなりません>>12

[30] 代替サービスにおける「十分な保証」は、HTTPSサーバー認証を使うことによります。 クライアントは、 HTTPSサーバー認証によりサーバー証明書要求起源について妥当である場合を除き、 当該接続で要求を送信してはなりません>>12

[52] TLS で定められたサーバー証明書の検証やHTTPSサーバー認証を正しく行わないと、 正しい相手と通信しているかを確認できません。 例えば平文で送信された代替サービス広告が改竄されている場合、 悪意ある第三者のサーバーに接続してしまっても気づけません。

最初の要求

[31] クライアントは、 まず要求起源に関して妥当な「http-opportunistic」応答を得なければなりません>>12

[35] 起源について妥当な「http-opportunistic」応答を持つ (have a valid "http-opportunistic" response) とは、 次の条件を満たすことをいいます。 >>12

[43] 大文字・小文字不区別が具体的にどのような比較によるものかは不明です。

[44] (配列に?) 含まれる値が文字列でない時、非妥当として構いません。 >>12

[45] https://.../.well-known/http-opportunistic や、 配列https:起源が含まれる場合の意味は、 定義されていません。 >>12

[46] 新鮮であるとの条件が暗示する通り、HTTPキャッシュの利用が認められています。 したがって、すべての代替サービスhttp://.../.well-known/http-opportunistic応答できる必要があります >>12クライアントは、当該代替サービスから http://.../.well-known/http-opportunistic を取得せずとも (キャッシュを使って) すぐに利用できます >>12

[47] クライアントは、認証されていない接続を使って得た http://.../.well-known/http-opportunisticキャッシュを使ってはなりません >>12

[48] ということは、HTTPキャッシュ蓄積された応答代替サービス経由の応答かどうかの情報を保持する必要があります。

[49] クライアントは、認証されていない接続を使って得た http://.../.well-known/http-opportunisticキャッシュにあっても、消去しなければなりません。 認証されていない接続の応答を認証された接続で再検証したところで、 応答一貫性は保てません。 >>12

[53] http://.../.well-known/http-opportunistic の検査が必要なのは、 従来 HTTPS でアクセスされた時 https: のアクセスとみなして応答を返す運用がなされてきたため、 真に Opportunistic HTTP/2 Security を意図したサーバーかどうかを確認するためです >>12

[54] 長年そのように運用されてきて本来そのままで問題なかった前提を変えてしまった Opportunistic HTTP/2 Security が技術的に筋悪な気がしますが。

接続の利用

[32] クライアントは、 同じ接続に異なる起源要求を送信してはなりません>>12

[33] http:https: とで接続を共有することはできません >>12

[34] 接続先代替サービスが同じだとしても、 異なるホストURL への要求接続を共有することはできません。

批判

[16] 中途半端なセキュリティーしか提供できない本技術は HTTPS への移行を遅らせるものだとして、 好ましくないと考える人もいます。

利用者インターフェイス

[50] http: URL応答TLS 経由で受け取っても、 https: のようなセキュリティーの表示を行ってはなりません>>12

実装

[15] Firefox が実装しています。

[17] 他の Webブラウザーが実装するかどうかは不明です。

歴史

[1] draft-ietf-httpbis-http2-encryption-01 - Opportunistic Security for HTTP ( 版) <https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-01>

[2] meetings/04-21-minutes.md at gh-pages · w3ctag/meetings ( 版) <https://github.com/w3ctag/meetings/blob/gh-pages/2015/04-sfo/04-21-minutes.md>

Mark: Only Mozilla is implementing Opportunistic Encryption [not shipped it]

Alex: [We on the Chrome team are adamently against Opportunistic Encryption because it doesn't solve any problems]

Mark: The IETF is generally enthusiastic about Opportunistic Security

Mark: The W3C is much less excited about Opportunistic Security

[3] draft-ietf-httpbis-http2-encryption-04 - Opportunistic Security for HTTP ( 版) <https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-04>

[4] draft-ietf-httpbis-http2-encryption-07 - Opportunistic Security for HTTP () <https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-07>

[5] RFC 8164 - Opportunistic Security for HTTP/2 () <https://tools.ietf.org/html/rfc8164>

[6] 1301117 - Update Opportunistic Security for HTTP () <https://bugzilla.mozilla.org/show_bug.cgi?id=1301117>

[7] 1003448 - http/2 alt-svc support () <https://bugzilla.mozilla.org/show_bug.cgi?id=1003448>

[8] 1172615 - opportunistic encryption potentially perturbing certificate verification telemetry () <https://bugzilla.mozilla.org/show_bug.cgi?id=1172615>

[9] 1148885 - Opportunistic Encryption does not work with HTTP/2 proxy () <https://bugzilla.mozilla.org/show_bug.cgi?id=1148885>

[10] 742610 - Remove opportunistic caching support from nsHttpChannel () <https://bugzilla.mozilla.org/show_bug.cgi?id=742610>

[11] 1148328 - (CVE-2015-0799) Server certificate verification bypass with Alt-Svc () <https://bugzilla.mozilla.org/show_bug.cgi?id=1148328>