[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 を使うもの (例えば h2HTTP/2) とします。 プロトコルは、資源の schemeURL scheme を明示的に示すものでなければなりません。 >>12

[20] HTTP/1.1 は要求対象に絶対URLを指定することを認めてはいますが、 (プロキシサーバーではなく) 起源サーバーに対して指定することは認めていませんので、 該当しません >>12。[27] 代替サービスのプロトコルの識別子は、 ALPN の識別子です。 原則として TLS 上のプロトコルを表していますが、 h2c のようにそうでないものもあり、ここでの条件に合致しないことになります。 ftp のように URL を指定できないプロトコルも、 schemeURL 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: も提供する場合に、 証明書要求することができます。 しかし、クライアントが証明書を提供しない場合にも、 ハンドシェイクTLSハンドシェイクを中断abortしてはなりません。 >>12

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

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

最初の要求

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

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

  • [36] 認証を経た接続で、 クライアントが /.well-known/http-opportunistic に要求を送信し、
  • [37] それに対する応答の状態状態符号が 200 であり、
  • [38] その応答が新鮮であり (必要なら再検証可)、
  • [39] その応答のMIME型が application/json であり、
  • [40] その応答の payload が RFC 7159 JSON であり、
  • [41] その JSON の根が配列であり、
  • [42] その配列に、起源の RFC 6454 Unicode直列化と大文字・小文字不区別で一致する文字列が含まれる
[43] 大文字・小文字不区別が具体的にどのような比較によるものかは不明です。

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

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

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

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

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

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

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

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

接続の利用

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

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

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

批判

[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