1. 序論
~INFORMATIVE利用者が、保安的~channel(例えば~HTTPS)越しに,成功裡に `example.com^s から資源を読込んだとき、~UAは,利用者の 保安/~privacy に~criticalな,次の 3 つを表明できる: ◎ When a user successfully loads a resource from example.com over a secure channel (HTTPS, for example), the user agent is able to make three assertions critical to the user’s security and privacy:
- 利用者が通信している~serverは、紛れもなく,利用者の要請が経由した数多の~serverのどれでもない, `example.com^s であると主張することが許容される。 接続は、認証-済みになれる。 ◎ The user is communicating with a server that is allowed to claim to be example.com, and not one of the many, many servers through which her request has hopped. The connection can be authenticated.
- 利用者と `example.com^s との通信は、介在者により自明に盗聴され得ない。 利用者が[ 発行した要請, 受信した応答 ]のいずれも暗号化されているので。 ◎ The user’s communications with example.com cannot be trivially eavesdropped upon by middlemen, because the requests she makes and the responses she receives are encrypted.
- 暗号化と認証は,~dataの完全性を保証するので、利用者と `example.com^s との通信は,介在者により自明に改変され得ない。 ◎ The user’s communications with example.com cannot be trivially modified by middlemen, the encryption and authentication provide a guarantee of data integrity.
これらの表明は一体として、利用者に次の二点を確約する:
- `example.com^s が,利用者の要請を読取って応答できる唯一の主体であること( caveat: without shocking amounts of work 【それも,多量の仕事をこなす必要なく?】 )
- 利用者が受信する~dataは,`example.com^s が実際に送信したものであること
しかしながら、これらの表明の強度は,暗号化され,かつ認証された当の資源が,非保安的~channel越しに下位資源(~script, 画像, 等々)を要請したときには、相当に弱められる。 非保安的~要請は,中間者~攻撃に無防備になるので、それらの資源~要請による結果,状態0が混在することになる。 あいにく,このような局面はごく共通的にある。 ◎ The strength of these assertions is substantially weakened, however, when the encrypted and authenticated resource requests subresources (scripts, images, etc) over an insecure channel. Those resource requests result in a resource whose status is mixed, as insecure requests are wide open for man-in-the-middle attacks. This scenario is unfortunately quite common.
この仕様は、~UAがこれらの保安と~privacyの~riskを[ それらの~riskに疑念なく不作為に通信する資源の能を制限する ]ことにより,軽減できる方法について詳細を述べる。 ◎ This specification details how a user agent can mitigate these risks to security and privacy by limiting a resource’s ability to inadvertently communicate in the clear.
注記: この文書に述べるどれもが、特に新しいものではなく,年月にわたり一つ以上の~UAに現れたものばかりである — ~version 4 の頃からの Internet Explorer を始めとして、混在~内容に対し利用者に~alertしている。 ◎ Note: Nothing described in this document is really new; everything covered here has appeared in one or more user agents over the years: Internet Explorer led the way, alerting users to mixed content since around version 4.
【この訳に固有の表記規約】
この訳の,~algoや定義の記述に利用されている各種記号( ~LET, ~EQ, ~IN, ~IF, ~RET, 等々)の意味や定義の詳細は、~SYMBOL_DEF_REFを~~参照されたし。
用語 `文書@ は、[ `Document$I ~interfaceを実装する~obj ]の略記である。
原文に現れる用語 `~target閲覧文脈@ は、現在は HTML 仕様の`~target閲覧文脈$enVを指しているが,おそらく誤っている。 この用語は、以前は `FETCH$r 仕様に定義されていた “要請の~target閲覧文脈” を指していたが,現在はその仕様から廃されている。
2. ~~主要な概念と各種用語
- `混在~内容@ ( `mixed content^en )
-
次の両者を満たす`要請$は、`混在~内容$とされる:
- その`~url$rqは`先天的に認証-済み~URL$でない
- その読込みを担当する文脈では、混在~保安~文脈の禁制が要求されている†
-
次の両者を満たす`応答$は、`混在~内容$とされる:
- `未認証の応答$である
- その読込みを担当する文脈では、混在~保安~文脈の禁制が要求されている†
- † 規範的な定義は、`設定群は混在~保安的~文脈を禁制するか?$を見よ。 ◎ ↑
-
混在~内容を制約する文脈(例: `https://secure.example.com/^s )の内側では: ◎ Inside a context that restricts mixed content (https://secure.example.com/, for example):
- `http://example.com/script.js^s にある~scriptに対する要請は`混在~内容$になる。 この`要請$は`阻止-可能$になるので、~UAは,資源を読込む代わりに~network~errorを返すことになる。 ◎ A request for the script http://example.com/script.js is mixed content. As script requests are blockable, the user agent will return a network error rather than loading the resource.
- `http://example.com/image.png^s にある画像に対する要請は`混在~内容$になる。 この`要請$は`随意に阻止-可能$になるので、~UAは その画像を読込むかもしれない — その場合、画像~資源~自身は`混在~内容$になる。 ◎ A request for the image http://example.com/image.png is mixed content. As image requests are optionally-blockable, the user agent might load the image, in which case the image resource itself would be mixed content.
- 混在~内容を制約する文脈の中に,混在~内容が読込まれた場合(上の例の 2 番目に示したように)、その文脈は( `RFC6797$r に定義されるように)`混在~保安的~文脈$と見なされる。 ◎ If mixed content is loaded into a context that restricts mixed content (as in #2 above), that context is considered a mixed security context (as defined in [RFC6797]).
- 注記: “混在~内容” は、元々は `WSC-UI$r の 5.3 節 にて定義された。 この文書は、それによる初期の定義を更新する。 ◎ Note: "Mixed content" was originally defined in section 5.3 of [WSC-UI]. This document updates that initial definition.
- 注記: `XML$r も,無関係な 混在~内容 の概念を定義しているが、この用語は,各~UAにわたる保安~文脈のほぼ至る所で 10 年以上 使われ続けているので、実用上は混同されるおそれは少ないであろう。 ◎ Note: [XML] also defines an unrelated "mixed content". concept. This is potentially confusing, but given the term’s near ubiquitious usage in a security context across user agents for more than a decade, the practical risk of confusion seems low.
- `先天的に認証-済み~URL@ ( `a priori authenticated URL^en )
-
特定0の~URL %url への要請は、次のいずれかが満たされるならば, 傍受と改変の~riskを軽減する仕方で送達されることが 先天的に 既知となる: ◎ We know a priori that a request to a particular URL (url) will be delivered in a way that mitigates the risks of interception and modifications if either of the following statements is true:
- %url は`信用に価し得る~URL$である `SECURE-CONTEXTS$r ◎ url is a potentially trustworthy URL [SECURE-CONTEXTS].
-
%url の`~scheme$ ~EQ `data^l ◎ url’s scheme is "data".
注記: ここでは `data^c ~URLは特別な事例として扱う — それらは特に信用に価し得るとは見なされないが、~networkは決して叩かないので,混在~内容として阻止したいと望まれてもいない。 ◎ Note: We special case data URLs here, as we don’t consider them particularly trustworthy, but we also don’t wish to block them as mixed content, as they never hit the network.
- `未認証の応答@ ( `unauthenticated response^en )
-
`応答$ %応答 は、次の両者を満たすならば,未認証であることが 後天的に 既知となる。 ◎ We know a posteriori that a response (response) is unauthenticated if both of the following statements are true:
- %応答 の`~url$rsは`先天的に認証-済み~URL$である ◎ response’s url is a priori authenticated.
- [ %応答 の`~url$rs の`~scheme$ ~IN { `https^l, `wss^l } ]~AND[ %応答 の`~HTTPS状態$rs ~IN { `modern^l } ] ◎ If response’s url’s scheme is "https" or "wss", response’s HTTPS state is "modern".
- 【 明らかに、語が示唆する意味と正反対の定義。 おそらく仕様の誤りであろう。 】
- `埋込んでいる文書@ ( `embedding document^en )
- `文書$ %A が`属する閲覧文脈$が `文書$ %B を`通して入子に$されているとき、 %B を指して, %A を埋込んでいる文書という。 `HTML$r ◎ Given a Document A, the embedding document of A is the Document through which A’s browsing context is nested [HTML].
3. 内容の分類
理想~世界では、各~UAには,あらゆる`混在~内容$をもれなく阻止することが要求されることになるが、あいにく今日の~Internetにおいては,それは実用的でない。 ~UAは、より按配よく制約しなければ,相当~数の~web~siteで利用者~体験の劣化は避けれなくなる。 ◎ In a perfect world, each user agent would be required to block all mixed content without exception. Unfortunately, that is impractical on today’s Internet; a user agent needs to be more nuanced in its restrictions to avoid degrading the experience on a substantial number of websites.
そのことを念頭に、ここでは,混在~内容を[ `随意に阻止-可能な内容$, `阻止-可能な内容$ ]の 2 つに分類する。 ◎ With that in mind, we here split mixed content into two categories: §3.1 Optionally-blockable Content and §3.2 Blockable Content.
注記: この仕様の将来~versionは、世界の`混在~内容$すべてが阻止される方へ進むべく,この分類法を更新することになる — それが最終的な目標であるが、今の所は,ここまでが最善である。 ◎ Note: Future versions of this specification will update this categorization with the intent of moving towards a world where all mixed content is blocked; that is the end goal, but this is the best we can do for now.
3.1. 随意に阻止-可能な内容
混在~内容は、[ `混在~内容$としての用法を許容する~risk ]より[ ~webの有意な部位を壊す~risk ]の方が重視されるとき, `随意に阻止-可能@ ( `optionally-blockable^en )とされる。 これは、当の資源~種別の混在~利用率が十分に高いこと,および 資源それ自体は低~riskであることによる。 この種の資源が随意に阻止-可能である事実が,安全であることを意味するわけではない — 単純に,他の種別の資源より破滅的な危険~度は低いことを意味する。 例えば画像や~iconは、~appの~interfaceにおいて中心的な~UI要素になることが多い。 攻撃者が~emailの[ “~~削除”, “~~返信” ]を表す~iconを逆にした場合、利用者に実害が及ぶことになる。 ◎ Mixed content is optionally-blockable when the risk of allowing its usage as mixed content is outweighed by the risk of breaking significant portions of the web. This could be because mixed usage of the resource type is sufficiently high, and because the resource is low-risk in and of itself. The fact that these resource types are optionally-blockable does not mean that they are safe, simply that they’re less catastrophically dangerous than other resource types. For example, images and icons are often the central UI elements in an application’s interface. If an attacker reversed the "Delete email" and "Reply" icons, there would be real impact to users.
これに分類されるものには次が挙げられる: ◎ This category includes:
-
次を満たす要請 ⇒ [ `起動元$rq ~EQ 空~文字列 ]~AND[ `行先$rq ~EQ `image^l ] ◎ Requests whose initiator is the empty string, and whose destination is "image".
注記: `img$e や~CSS ( `background-image$css, `border-image$css, 等々)を介して読込まれるほとんどの画像は、これに対応する(画像として読込まれる~SVG文書も含まれる — それらによる[ ~scriptの実行/下位資源の~fetching ]は阻止されるので)。 `img$e 要素のうち `srcset^a または `picture^e を利用して いるものは含まれない。 ◎ Note: This corresponds to most images loaded via img (including SVG documents loaded as images, as those are blocked from executing script or fetching subresources) and CSS (background-image, border-image, etc). It does not include img elements that use srcset or picture.
-
次を満たす要請 ⇒ `行先$rq ~EQ `video^l ◎ Requests whose destination is "video".
注記: `video$e / `source$e を介して読込まれる動画は、これに対応する。 ◎ Note: This corresponds to video loaded via video and source.
-
次を満たす要請 ⇒ `行先$rq ~EQ `audio^l ◎ Requests whose destination is "audio".
注記: `audio$e / `source$e を介して読込まれる音声は、これに対応する。 ◎ Note: This corresponds to audio loaded via audio and source.
注記: この分類は、`要請の~fetchingは混在~内容として阻止されるべきか?$において,[ CORS が可能化された要請は 強制的に失敗させる ]ことにより、更に制限される。 これは例えば、 <`img$e `crossorigin$a ...> を介して読込まれる混在~内容~画像は阻止されることを意味する。 上に挙げたものは、[ この分類に該当する内容は,[ 全面的に阻止するには,広範に利用され過ぎている ]ものに限られる ]とする、一般~原則の好例である。 Working Group は、時を経るに伴い,より阻止-可能な下位集合を形作ることを意図している。 ◎ We further limit this category in §5.2 Should fetching request be blocked as mixed content? by force-failing any CORS-enabled request. This means, for example, that mixed content images loaded via <img crossorigin ...> will be blocked. This is a good example of the general principle that content falls into this category only when it is too widely used to be blocked outright. The Working Group intends to carve out more blockable subsets as time goes on.
3.2. 阻止-可能な内容
上に定義した`随意に阻止-可能$でない,どの混在~内容も `阻止-可能@ ( `blockable^en )と見なされる。 この種の内容の代表的な例には、 ~script, `~plugin$~data, `XMLHttpRequest$I を介して要請される~data, 等々がある。 ◎ Any mixed content that is not optionally-blockable as defined above is considered to be blockable. Typical examples of this kind of content include scripts, plugin data, data requested via XMLHttpRequest, and so on.
注記: `~navi要請$は、`~top-level閲覧文脈$を~targetすることもあるが,混在~内容とは見なされない。 詳細は、`要請の~fetchingは混在~内容として阻止されるべきか?$を見よ。 ◎ Note: Navigation requests might target top-level browsing contexts; these are not considered mixed content. See §5.2 Should fetching request be blocked as mixed content? for details.
注記: ~pluginが自身に利するために発行する要請は、阻止-可能になる。 しかしながら、~UAが常に,そのような要請を仲介する立場にあるとは限らないことも認識されている。 具体例として、 NPAPI ~pluginは,直接的な~network~accessを有することが多く、一般に~UAをまるごと迂回できる。 ~UAには、可能なときは,これらの要請を阻止することが推奨される。 ~plugin~vendorには、自身における混在~内容の検査-法を実装して,この文書に概説する~riskを軽減することが推奨される。 ◎ Note: Note that requests made on behalf of a plugin are blockable. We recognize, however, that user agents aren’t always in a position to mediate these requests. NPAPI plugins, for instance, often have direct network access, and can generally bypass the user agent entirely. We recommend that user agents block these requests when possible, and that plugin vendors implement mixed content checking themselves to mitigate the risks outlined in this document.
4. 混在~内容の厳格な検査-法
作者は、[ `随意に阻止-可能$, `阻止-可能$ ]の両~混在~内容とも阻止するような,より厳格な混在~内容の検査-法を可能化することを選んでも~MAY。 これにより、利用者による上書き~option(`利用者による制御 節$)も抑止され、利用者に提示される保安~UIが混在~内容により劣化することは — `~UIに課される要件 節$に述べるように — 決してないことが確約される。 ◎ In order to give authors assurance that mixed content will never degrade the security UI presented to their users (as described in §7.3 UI Requirements), authors may choose to enable a stricter variant of mixed content checking which will both block optionally-blockable and blockable mixed content, and suppress the user override options discussed in §7.4 User Controls.
そのようなわけで、各[ `文書$/`閲覧文脈$ ]は, `厳格~検査~flag@ ( `strict mixed content checking flag^en, “混在~内容に対し厳格に検査するかどうかを指示する~flag” )を有する。 それは、他が指定されない限り ~OFF とする。 この~flagは、[ `要請の~fetchingは混在~内容として阻止されるべきか?$ / `要請に対する応答は混在~内容として阻止されるべきか?$ ]にて`文書$が `厳格~mode@ ( `strict mode^en )下にあるかどうか決定するときに検査される。 ◎ To this end, Document objects and browsing contexts have a strict mixed content checking flag which is set to false unless otherwise specified. This flag is checked in both §5.2 Should fetching request be blocked as mixed content? and §5.3 Should response to request be blocked as mixed content? to determine whether the Document is in strict mode.
`文書$は、次のいずれかにより,自身の中に厳格~modeを~opt-inして~MAY:
-
次の様な `Content-Security-Policy$h ~HTTP~headerを送達するか: ◎ A Document may opt itself into strict mode by either delivering a Content-Security-Policy HTTP header, like:
Content-Security-Policy: `block-all-mixed-content$dir
-
または、`埋込んでいる文書$の `meta$e 要素に次の様な施策を与える: ◎ or by embedding the policy in a meta element, like:
<meta http-equiv="Content-Security-Policy" content="`block-all-mixed-content$dir">
注記: 混在~内容の厳格な検査-法は、埋込みの内容にも継承される。 ある~pageが厳格~modeを~opt-inした場合、~frame内に入子にされた~pageにおいても — `~opt-inの継承-法 節$に述べるように — 混在~内容の読込みは防止されることになる。 ◎ Note: Strict mixed content checking is inherited by embedded content; if a page opts into strict mode, framed pages will be prevented from loading mixed content, as described in §4.4 Inheriting an opt-in.
4.1. 効果
[ `文書$の`厳格~検査~flag$ ~EQ ~ON ]の場合、~UAには,次が要求される: ◎ If a Document's strict mixed content checking flag is set to true, the user agent MUST:
- `随意に阻止-可能$な混在~内容を,`阻止-可能$であったかのように扱う。 ◎ treat optionally-blockable mixed content as though it were blockable.
-
利用者には、`阻止-可能$な混在~内容の読込みを強制する仕組みを供さない。 ◎ NOT provide users with a mechanism for forcing blockable mixed content to load.
注記: この要件は、`利用者による制御 節$における示唆を上書きする。 ◎ Note: This requirement overrides the suggestion in §7.4 User Controls.
-
混在~内容の存在0について,いかなる指示も利用者~向けに供さない。 ◎ NOT provide any user-facing indication that mixed content is present.
注記: この要件は、`~UIに課される要件 節$における示唆を上書きする。 上の 1 番目と 2 番目の要件の組合せにより,[ 当の~pageの文脈~下では,混在~内容は決して読込まれない ]ことが確保され、そうしても安全なので。 ◎ Note: This requirement overrides the suggestion in §7.3 UI Requirements, which is safe to do since the combination of the first and second requirements above ensure that mixed content will never load in this page’s context.
注記: この要件には、~console-messageなどの,開発者~向けの指示子は含まれない。 ◎ Note: This requirement does not include developer-facing indicators such as console messages.
- これらの要件が、[ `入子の閲覧文脈$に属するどの`文書$にも適用される ]ことを — `~opt-inの継承-法 節$に述べるように — 確保する。 ◎ ensure that these requirements are applied to any Document in a nested browsing context, as described in §4.4 Inheriting an opt-in.
4.2. ~opt-in法
作者は、~CSP指令 `CSP3$r `block-all-mixed-content@dir を介して,`文書$の中に 混在~内容の厳格な検査-法を~opt-inして~MAY。 この指令は次の ABNF 文法を介して定義される。 ◎ Authors may opt a Document into strict mixed content checking via a block-all-mixed-content Content Security Policy directive [CSP3], defined via the following ABNF grammar.
`directive-name$P = "block-all-mixed-content" `directive-value$P = ""
この指令は、~page上の混在~内容に対する違反~報告を誘発することになる。 詳細は、`要請の~fetchingは混在~内容として阻止されるべきか?$に。 ◎ This directive will trigger violation reports for mixed content on a page. Details are found in §5.2 Should fetching request be blocked as mixed content?.
注記: 個々の指令を設定すれば、類似する効果を より細かい~levelで達成できる。 例えば `img-src$dir https: は、非保安的~画像の読込みを防止することになる。 ◎ Note: A similar effect may be achieved on a more granular level by setting individual directives. For example img-src https: would prevent insecure images from loading.
4.3. `block-all-mixed-content^dir の初期化
`block-all-mixed-content$dir の`初期化~algo$は、所与の ( `文書$または`大域~obj$ %文脈, `応答$ %応答, `施策$ %施策 ) に対し,次に従う: ◎ block-all-mixed-content's initialization algorithm is as follows: ◎ Given a Document or global object (context), a response (response), and a policy (policy):
- ~Assert: %応答 は利用されない。 ◎ Assert: response is unused.
- ~IF[ %施策 の`処置先$ ~NEQ `enforce^l ] ⇒ ~RET ◎ If policy’s disposition is not "enforce", then abort this algorithm.
- %文脈 の`厳格~検査~flag$ ~SET ~T ◎ Set context’s strict mixed content checking flag to true.
4.4. ~opt-inの継承-法
~UAは、すべての`入子の閲覧文脈$に対し,次に従って`厳格~検査~flag$を継承させ~MUST: ◎ If a Document's strict mixed content checking flag is set, the user agent MUST ensure that all nested browsing contexts inherit the setting in the following ways:
- `入子の閲覧文脈$ %文脈 の作成-時には ⇒ ~IF[ %文脈 を`埋込んでいる文書$の`厳格~検査~flag$ ~EQ ~ON ] ⇒ %文脈 の`厳格~検査~flag$ ~SET ~ON ◎ When a nested browsing context context is created, set its strict mixed content checking flag to true if context’s embedding document’s strict mixed content checking flag is set to true.
- `新たな文書の初期化-時$には ⇒ ~IF[ その`文書$ %文書 が`属する閲覧文脈$の`厳格~検査~flag$ ~EQ ~ON ] ⇒ %文書 の`厳格~検査~flag$ ~SET ~ON ◎ When creating a new Document object, set its strict mixed content checking flag to true if its browsing context’s strict mixed content checking flag is true.
5. 保安的な文脈における非保安的~内容
高~levelからは、次の~algoにより,特定0の要請が[ 成功するべきか, ~network~errorになるべき ]かどうか,~UAは決定できるようになる: ◎ At a high level, the following algorithms allow user agents to determine whether particular requests should succeed, or should result in network errors.
- ~algo[ `要請の~fetchingは混在~内容として阻止されるべきか?$ ]は、 ~fetch `FETCH$r ~algoの最初の方で,[ `先天的に認証-済み~URL$でない`~url$rqへの~network流通を阻止する ]ために~callされる。 この~hookは、初期~要請のみならず,すべての~redirectも捕えれることを確保する。 ◎ Fetch calls the algorithm defined in §5.2 Should fetching request be blocked as mixed content? at the top of the fetching algorithm in order to block network traffic to URLs which are not a priori authenticated [FETCH]. Hooking into Fetch here ensures that we catch not only the initial request, but all redirects as well.
-
~algo[ `要請に対する応答は混在~内容として阻止されるべきか?$ ]もまた、~fetch~algoの最後の方で,[ `未認証の応答$を阻止する ]ために~callされる。 この~hookは、次のために必要とされる:
- `ServiceWorker$I により[ 改変-/合成- ]された資源を検出する
- ~TLS-handshakeを終えた後に,応答が`未認証の応答$であるかどうか決定する
詳細は、[ `要請に対する応答は混在~内容として阻止されるべきか?$ ]の段 4.1, 4.2 を見よ。 【この段~番号はおそらく誤り】
◎ Further, Fetch calls the algorithm defined in §5.3 Should response to request be blocked as mixed content? at the bottom of the fetching algorithm in order to block unauthenticated responses. This hook is necessary to detect resources modified or synthesized by a ServiceWorker, as well as to determine whether a response is unauthenticated once the TLS-handshake has finished. See steps 4.1 and 4.2 of the algorithm defined in §5.3 Should response to request be blocked as mixed content? for detail. -
~algo[ `設定群は混在~保安的~文脈を禁制するか?$ ]は、[ 非保安的~要請は阻止されるべきかどうか決定する ]ために,次の箇所から利用される:
- `要請の~fetchingは混在~内容として阻止されるべきか?$
- `要請に対する応答は混在~内容として阻止されるべきか?$
- ~WebSocketに対する改変 節
5.1. %設定群 は混在~保安~文脈を禁制するか?
`文書$, ~worker のいずれも,`環境~設定群~obj$を有する。 この %設定群 は、[ 混在~内容を制約するかどうか ]を決定するために,次の~algoに則って精査され得る。 この~algoは、[ `禁制する^i, `禁制しない^i ]のいずれかを返す: ◎ Both documents and workers have environment settings objects which may be examined according to the following algorithm in order to determine whether they restrict mixed content. This algorithm returns "Prohibits Mixed Security Contexts" or "Does Not Prohibit Mixed Security Contexts", as appropriate. ◎ Given an environment settings object (settings):
- ~IF[ %設定群 の`~HTTPS状態$enV ~NEQ `none^l ] ⇒ ~RET `禁制する^i ◎ If settings’ HTTPS state is not "none", then return "Prohibits Mixed Security Contexts".
-
~IF[ %設定群 の`担当の文書$enV %文書 はある ]: ◎ If settings has a responsible document document, then:
-
~WHILE[ %文書 を`埋込んでいる文書$はある ] : ◎ While document has an embedding document:
- %文書 ~SET %文書 を`埋込んでいる文書$ ◎ Set document to document’s embedding document.
- %埋込元~設定群 ~LET %文書 の`大域~obj$に`関連する設定群~obj$ ◎ Let embedder settings be document’s global object's relevant settings object.
- ~IF[ %埋込元~設定群 の`~HTTPS状態$enV ~NEQ `none^l ] ⇒ ~RET `禁制する^i ◎ If embedder settings’ HTTPS state is not "None", then return "Prohibits Mixed Security Contexts".
-
- ~RET `禁制しない^i ◎ Return "Does Not Restrict Mixed Security Contexts".
注記: 文書を`埋込んでいる文書$がある場合、~UAは,文書~自身のみならず,文書を入子にしている`~top-level閲覧文脈$も検査する必要がある — それが、[[ 利用者が読込んだ資源の保安~状態0 ]に関する利用者の期待 ]を制御する文脈なので。 例えば: ◎ If a document has an embedding document, a user agent needs to check not only the document itself, but also the top-level browsing context in which the document is nested, as that is the context which controls the user’s expectations regarding the security status of the resource she’s loaded. For example:
- `http://a.com^s が `http://evil.com^s を読込む場合 ⇒ `evil.com^s への非保安的~要請は、許容されることになる — `a.com^s は 保安的~接続~越しに読込まれていないので。 ◎ http://a.com loads http://evil.com. The insecure request will be allowed, as a.com was not loaded over a secure connection.
- `https://a.com^s が `http://evil.com^s を読込む場合 ⇒ `evil.com^s への非保安的~要請は、阻止されることになる — `a.com^s は 保安的~接続~越しに読込まれたので。 ◎ https://a.com loads http://evil.com. The insecure request will be blocked, as a.com was loaded over a secure connection.
- `http://a.com^s が~frame内に `https://b.com^s を入子にしていて, `b.com^s は `http://evil.com^s を読込む場合 ⇒ `evil.com^s への非保安的~要請は阻止されることになる — `a.com^s は そうでなくても, `b.com^s は 保安的~接続~越しに読込まれたので。 ◎ http://a.com frames https://b.com, which loads http://evil.com. In this case, the insecure request to evil.com will be blocked, as b.com was loaded over a secure connection, even though a.com was not.
- `https://a.com^s が~frame内に ~data_scheme ~URLを入子にしていて,その ~data_scheme ~URLは `http://evil.com^s を読込む場合 ⇒ `evil.com^s への非保安的~要請は阻止されることになる — ~top-level文脈における ~data_scheme ~URLは 混在~内容を阻止しないが, `a.com^s は 保安的~接続~越しに読込まれたので。 ◎ https://a.com frames a data: URL, which loads http://evil.com. In this case, the insecure request to evil.com will be blocked, as a.com was loaded over a secure connection, even though the framed data: URL would not block mixed content if loaded in a top-level context. data: URL is not a priori authenticated.
5.2. %要請 の~fetchingは混在~内容として阻止されるべきか?
注記: ~Fetch仕様は、要請をまるごと阻止する†べきかどうか決定するために,この~algoの中へ~hookする。 † 例えば 当の要請は、`阻止-可能$な内容に対するものであり,保安的~接続~越しに読込まれることは ないと見做せることから。 ◎ Note: The Fetch specification hooks into this algorithm to determine whether a request should be entirely blocked (e.g. because the request is for blockable content, and we can assume that it won’t be loaded over a secure connection).
~UAは、次の~algoを介して,所与の`要請$ %要請 を続行するべきかどうかを決定する: ◎ Given a Request request, a user agent determines whether the Request request should proceed or not via the following algorithm:
-
~IF[ 次のいずれかが満たされる ] ⇒ ~RET `許容ed^i: ◎ Return allowed if one or more of the following conditions are met:
- `設定群は混在~保安的~文脈を禁制するか?$( %要請 の`~client$rq ) の結果 ~EQ `禁制しない^i ◎ §5.1 Does settings prohibit mixed security contexts? returns "Does Not Restrict Mixed Security Contexts" when applied to request’s client.
- %要請 の`~url$rqは`先天的に認証-済み~URL$である ◎ request’s url is a priori authenticated.
- ~UAは — `利用者による制御 節$に述べるように — `混在~内容$を許容するよう指図されている ◎ The user agent has been instructed to allow mixed content, as described in §7.4 User Controls).
-
[ %要請 の`行先$rq ~EQ `document^l ]~AND[ %要請 の`~target閲覧文脈$の`親~閲覧文脈$ ~EQ ε ] ◎ request’s destination is "document", and request’s target browsing context has no parent browsing context.
注記: ~top-level~naviは,混在~内容~検査からは除外されるが、~UAは,非保安的~form提出に対しては 混在~内容~検査を施行することを選んで~MAY(`更なる動作 節$を見よ)。 ◎ Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see §7.5 Further Action).
-
%要請 の`~client$rqの`~CSP~list$内の ~EACH( %施策 ) に対し: ◎ For each policy in request’s client’s CSP list:
-
~IF[ %施策 の`指令~集合$内に[ `指令~名$ ~EQ `block-all-mixed-content$dir ]なる`指令$がある ]: ◎ If policy’s directive set contains a directive whose name is "block-all-mixed-content":
- %違反 ~LET ( %要請 の`~client$rqの`大域~obj$enV, %施策, `block-all-mixed-content^l ) から`違反~objを作成-$した結果 ◎ Let violation be the result of executing the algorithm defined in Content Security Policy §2.3.1 Create a violation object for global, policy, and directive on request’s client’s global object, policy, and "block-all-mixed-content".
- %違反 の`資源$ ~SET %要請 の`~url$rq ◎ Set violation’s resource to request’s url.
- %違反 を用いて`違反を報告-$する ◎ Execute the algorithm defined in Content Security Policy §5.2 Report a violation on violation.
-
-
~IF[ 次のいずれかが満たされる ] ⇒ ~RET `阻止ed^i: ◎ Return blocked if one or more of the following conditions are met:
- ~UAは — `利用者による制御 節$に述べるように — `随意に阻止-可能$な混在~内容を阻止するよう環境設定されている ◎ The user agent is configured to block optionally-blockable mixed content, as described in §7.4 User Controls.
- %要請 の`~client$rqの`厳格~検査~flag$ ~EQ ~ON ◎ request’s client’s strict mixed content checking flag is true.
- %要請 の`~mode$rq ~IN { `CORS^l, `CORS-with-forced-preflight^l } ◎ request’s mode is CORS or CORS-with-forced-preflight.
-
~IF[ 次のいずれかが満たされる ] ⇒ ~RET `許容ed^i: ◎ Return allowed if one or more of the following conditions are met:
- [ %要請 の`行先$rq ~EQ `image^l ]~AND[ %要請 の`起動元$rq ~NEQ `imageset^l ] ◎ request’s destination is "image", and initiator is not "imageset".
- %要請 の`行先$rq ~EQ `video^l ◎ request’s destination is "video".
- %要請 の`行先$rq ~EQ `audio^l ◎ request’s destination is "audio".
- ~RET `阻止ed^i ◎ Return blocked.
5.3. %要請 に対する %応答 は混在~内容として阻止されるべきか?
注記: 要請が続行される 場合でも,依然として、対する応答を,それを生成した接続の状態に基づいて 阻止するよう求められることがある(例: 要請は`阻止-可能$であるが,接続は`未認証$であるためなど)。 加えて,[ ~Service-Workerが、`阻止-可能$な要請に対し,不用意に`未認証の応答$を返さない ]ことも確保する必要がある。 この~algoは、これらを決定するために利用される。 ◎ Note: If a request proceeds, we still might want to block the response based on the state of the connection that generated the response (e.g. because the request is blockable, but the connection is unauthenticated), and we also need to ensure that a Service Worker doesn’t accidentally return an unauthenticated response for a blockable request. This algorithm is used to make that determination.
~UAは、次の~algoに従って,所与の ( `要請$ %要請, `応答$ %応答 ) に対し,応答を返すべきかどうかを決定する: ◎ Given a request request and response response, the user agent determines what response should be returned via the following algorithm:
-
~IF[ 次のいずれかが満たされる ] ⇒ ~RET `許容ed^i: ◎ Return allowed if one or more of the following conditions are met:
- `設定群は混在~保安的~文脈を禁制するか?$( %要請 の`~client$rq ) の結果 ~EQ `禁制しない^i ◎ §5.1 Does settings prohibit mixed security contexts? returns Does Not Restrict Mixed Content when applied to request’s client.
- %応答 の`~HTTPS状態$rs ~EQ `modern^l ◎ response’s HTTPS state is modern.
- ~UAは — `利用者による制御 節$に述べるように — `混在~内容$を許容するよう指図されている。 ◎ The user agent has been instructed to allow mixed content, as described in §7.4 User Controls).
-
[ %要請 の`行先$rq ~EQ `document^l ]~AND[ %要請 の`~target閲覧文脈$の`親~閲覧文脈$はない ] ◎ request’s destination is "document", and request’s target browsing context has no parent browsing context.
注記: ~top-level~naviは,混在~内容~検査からは除外されるが、~UAは,非保安的~form提出に対しては 混在~内容~検査を施行することを選んで~MAY(`更なる動作 節$を見よ)。 ◎ Note: We exclude top-level navigations from mixed content checks, but user agents MAY choose to enforce mixed content checks on insecure form submissions (see §7.5 Further Action).
-
~IF[ 次のいずれかが満たされる ] ⇒ ~RET `阻止ed^i: ◎ Return blocked if one or more of the following conditions are met:
- ~UAは — `利用者による制御 節$に述べるように — `随意に阻止-可能$な混在~内容を阻止するよう環境設定されている ◎ The user agent is configured to block optionally-blockable mixed content, as described in §7.4 User Controls.
- %要請 の`~client$rqの`厳格~検査~flag$ ~EQ ~ON ◎ request’s client’s strict mixed content checking flag is true.
-
~IF[ %応答 は`不透明な絞込み応答$である ]~AND[ 次のいずれかが満たされる ] ⇒ ~RET `許容ed^i: ◎ Return allowed if response is an opaque filtered response and one or more of the following conditions are met:
- [ %要請 の`行先$rq ~EQ `image^l ]~AND[ %要請 の`起動元$rq ~NEQ `imageset^l ] ◎ request’s destination is "image", and initiator is not "imageset".
- %要請 の`行先$rq ~EQ `video^l ◎ request’s destination is "video".
- %要請 の`行先$rq ~EQ `audio^l。 ◎ request’s destination is "audio".
- ~RET `阻止ed^i ◎ Return blocked.
6. ~WebSocketに対する改変
`WebSocket()$m 構築子~algo `WEBSOCKETS$r は、次に従って改変される: ◎ The WebSocket() constructor algorithm [WEBSOCKETS] is modified as follows:
- 現在の段 2 を除去する ◎ Remove the current step 2.
注記: この示唆は bug #28841 に対し~~提出されたものである。 `WEBSOCKETS$r ◎ Note: This suggestion is filed as bug #28841 against [WEBSOCKETS].
`~WebSocket接続を確立する~algo$ `RFC6455$r は、次に従って改変される: ◎ The Establish a WebSocket Connection algorithm [RFC6455] is modified as follows:
-
現在の段 1 の後に,次の段を遂行する: ◎ After the current step 1, perform the following step:
- [ %secure ~EQ ~F ]~AND[ `設定群は混在~保安的~文脈を禁制するか?$( %~client の`大域~obj$enVに`関連する設定群~obj$ ) の結果 ~EQ `禁制する^i ]ならば ⇒ ~clientは、`~WebSocket接続を失敗させ$た上で,接続を中止し~MUST `RFC6455$r ◎ If secure is false, and the algorithm in §5.1 Does settings prohibit mixed security contexts? returns "Restricts Mixed Security Context" when applied to client’s global object’s relevant settings object, then the client MUST fail the WebSocket connection and abort the connection [RFC6455].
-
現在の段 5 の後に,次の段を遂行する: ◎ After the current step 5, perform the following step:
-
[ %secure ~EQ ~T ]~AND[ 段 5 で遂行した ~TLS-handshakeの結果による~HTTPS状態 ~EQ `deprecated^l ]ならば ⇒ ~clientは`~WebSocket接続を失敗させ$た上で,接続を中止し~MUST `RFC6455$r ◎ If secure is true, and the TLS handshake performed in step 5 results in an HTTPS state of "deprecated", then the client MUST fail the WebSocket connection and abort the connection [RFC6455].
この段は、ごく説明的なものに過ぎない。 【参考: `Fetch$r 仕様の ~WebSocketに対する改め節。】 ◎ This is super hand-wavey.
-
注記: `RFC6455$r に対する 正誤表 #4398 として~~提出されている。 ◎ Note: Filed as errata #4398 against [RFC6455].
これらの変更点により、 `WebSocket$I ~objの構築-時に `SecurityError^E 例外が直に投出されることはなくなり、それに代わって,[ 接続を阻止して`~WebSocket接続を失敗させ$る ]ことに依拠することになる — 開発者は、 `WebSocket$I ~objの `onerror$m ~handlerを通して,それを捕えれる。 これにより、[ `XMLHttpRequest$I / `EventSource$I / `fetch()$m ]と 挙動が一貫するようになる。 ◎ These changes together mean that we’ll no longer throw a SecurityError exception directly upon constructing a WebSocket object, but will instead rely upon blocking the connection and triggering the fail the WebSocket connection algorithm, which developers can catch by hooking a WebSocket object’s onerror handler. This is consistent with the behavior of XMLHttpRequest, EventSource, and fetch().
7. 保安, および~privacy上の考慮点
7.1. 限界
混在~内容の阻止-法は、序論 節にて論じた保証を確保してくれる。 しかしながら,その保証は、[ 能動的な~network攻撃者が,伝送路を流れる[ ~code/内容 ]の~criticalな~bitを置換する ]ことに抗して,開発者や利用者を保護することに限られることに注意。 それは、[ 弱体化され,改ざんされた資源を送信するよう強要された~server ]に抗する保護は~~供さない。 ◎ Blocking mixed content allows us to ensure that the guarantees discussed in §1 Introduction are upheld. Note, however, that those guarantees only protect developers and users against active network attackers who would otherwise be able to replace critical bits of code or content on the wire as it flows past. They do not protect against a compromised server that itself is coerced into sending corrupted resources.
Subresource Integrity ( “下位資源の完全性” ) `SRI$r などの仕組みは、この種の脅威に~~対処するために設計されている。 ~web開発者には、可能0なときは,それを用立てることを推奨する。 ◎ Mechanisms such as Subresource Integrity [SRI] are designed to deal with this kind of threat, and we recommend that web developers make use of them whenever possible.
7.2. ~form提出
`文書$ %文書 に対し,[ `設定群は混在~保安的~文脈を禁制するか?$( %文書 に`関連する設定群~obj$ ) の結果 ~EQ `禁制する^i ]の場合、~UAは, %文書 内に[ 値が`先天的に認証-済み~URL$でない `action$a 属性 ]を有する `form$e 要素が在するときには,そのことを利用者に警告しても~MAY。 ◎ If §5.1 Does settings prohibit mixed security contexts? returns Restricts Mixed Content when applied to a Document's relevant settings object, then a user agent MAY choose to warn users of the presence of one or more form elements with action attributes whose values are not a priori authenticated URLs.
注記: 例えば現在の Chrome は、非保安的~form動作を伴う~pageの~UIを,非保安的~画像を表示する~pageに対するときと同じに扱う。 ◎ Note: Chrome, for example, currently gives the same UI treatment to a page with an insecure form action as it does for a page that displays an insecure image.
~UAは更に、そのような`文書$からの~form提出を — 文書が`~top-level閲覧文脈$に属する場合でも — `阻止-可能$な要請と扱って~MAY。 ◎ Further, a user agent MAY treat form submissions from such a Document as a blockable request, even if the submission occurs in the top-level browsing context.
7.3. ~UIに課される要件
~UAは、[ 通常時は、`~top-level閲覧文脈$が保安的であるときは,そのことを利用者に指示する ]のであれば: ◎ If a user agent would normally indicate to the user that the top-level browsing context is secure, then:
-
`混在~内容$への`要請$に対する応答として資源を返すことにより,当の文脈を`混在~保安的~文脈$に降格するときは(`要請$は `随意に阻止-可能$である,あるいは `阻止-可能$な`要請$を許容するよう環境設定されていることにより):
- 利用者に,同じ[ 保安的であることの指示 ]を供しては~MUST_NOT。
- 代わりに,`混在~内容$の存在0を指示する~SHOULDである。
~UAは,混在~内容の存在0を指示するときは、支援技術の利用者にも,~accessibility~APIを通して それを可用にし~MUST。 ◎ If a mixed content indication is present, it MUST be made available through accessibility APIs for users of assistive technologies.
注記: この節の要件は、 EV 状態0 `CAB$r の文脈においても保持される。 EV 証明書の指示子により,[ 混在~内容に対する違反を,利用者~向けに通知する必要性 ]が上書きされることはない。 ◎ Note: This requirement holds even in the context of an EV status [CAB]. An EV certificate’s indicator does not override the necessity to notify users of mixed content violations.
7.4. 利用者による制御
~UAは、すべての`混在~内容$を`阻止-可能$として扱う(すなわち,`随意に阻止-可能$な混在~内容であっても阻止する)かどうかについて,利用者が直に決める能を提供して~MAY。 ◎ A user agent MAY offer users the ability to directly decide whether or not to treat all mixed content as blockable (meaning that even optionally-blockable mixed content would be blocked).
注記: 供された場合、利用者には,そのような~optionの利点を採ることが強く推奨される。 ◎ Note: It is strongly recommended that users take advantage of such an option if provided.
~UAは、特定0の~page上で[ `阻止-可能$な混在~内容を阻止する裁定 ]を上書きする 【阻止しなくする】 能を,利用者に提供して~MAY。 ◎ A user agent MAY offer users the ability to override its decision to block blockable mixed content on a particular page.
注記: 実施上は、~UAはおそらく,そのような裏口を提供したままで済ますわけにはいかない。 すなわち、混在~scriptを許容する~optionは,特に危険である。 ~UAは,そのような選択肢を — 熟慮の下で[ 孕まれる~riskについて利用者に伝え, やりとりする ]ことなく — 提示することは,~~本当はやってはいけない( REALLY SHOULD NOT `RFC6919$r ) 。 ◎ Note: Practically, a user agent probably can’t get away with not offering such a back door. That said, allowing mixed script is in particular a very dangerous option, and each user agent REALLY SHOULD NOT [RFC6919] present such a choice to users without careful consideration and communication of the risk involved.
そのような制御を提供する~UAは、支援技術の利用者に対しても,~accessibility~APIを通して提供し~MUST。 ◎ Any such controls offered by a user agent MUST also be offered through accessibility APIs for users of assistive technologies.
7.5. 更なる動作
~UAには、開発者に混在~内容を埋込まないことを奨励するため,この文書に概説した要件~以上の,更なる動作を採ることが奨励される。 ◎ A user agent is encouraged to take further action above and beyond the requirements this document outlines in order to discourage developers from embedding mixed content.
具体例として、~UAは次を採ることもできる: ◎ For instance, a user agent could:
- `Strict-Transport-Security^h ~header~fieldの存在0を,[ すべての内容を`阻止-可能$に分類するよう強制する `RFC6797$r ], あるいは[ 混在~内容の検査-時に`厳格~mode$を可能化する ]ものとして解釈する。 ◎ Interpret the presence of a Strict-Transport-Security header field as forcing all content into the blockable category [RFC6797], or as a signal to enable strict mode for mixed content checking.
- `混在~内容$であって`随意に阻止-可能$な資源に対する要請を,利用者の~riskが抑制されるように改変する — ~cookieその他の認証~tokenを要請から剥取ったり,~schemeの自動的な昇格を試みる,等々。 ◎ Modify requests for optionally-blockable resources which are mixed content in order to reduce the risk to users: cookies and other authentication tokens could be stripped from the requests, automatic scheme upgrades could be attempted, and so on.
- `入子の閲覧文脈$の内側にある`随意に阻止-可能$な資源を,`阻止-可能$として扱って、~siteが,混在~内容が導入されるおそれなく資源を埋込めるようにする。 ◎ Treat optionally-blockable resources inside nested browsing contexts as blockable, to allow sites to embed resources without fear of introducing mixed content.
8. IANA 考慮点
~CSP指令~registry `RFC7762$r は、次の指令および参照先で更新されるべきである: ◎ The Content Security Policy Directive registry should be updated with the following directives and references [RFC7762]:
- `block-all-mixed-content$dir
- この文書( ~opt-in法 節 ) ◎ This document (see §4.2 Opting-in)
9. 謝辞
WebAppSec WG から集められた,賞賛すべき~feedbackに加えて、 Chrome の保安~teamは,この仕様の準備に計り知れなく~~寄与された。 特に、早期に多数の~feedbackを寄せられた各~氏: Chris Palmer, Chris Evans, Ryan Sleevi, Michal Zalewski, Ken Buchanan, and Tom Sepez 。 Fetch を説明され、この仕様への~interfaceを定義することに助力された Anne van Kesteren 氏。 この仕様を注目させ, 手入れし, 健全に保つことに助力された Brian Smith 氏。 ◎ In addition to the wonderful feedback gathered from the WebAppSec WG, the Chrome security team was invaluable in preparing this specification. In particular, Chris Palmer, Chris Evans, Ryan Sleevi, Michal Zalewski, Ken Buchanan, and Tom Sepez gave lots of early feedback. Anne van Kesteren explained Fetch and helped define the interface to this specification. Brian Smith helped keep the spec focused, trim, and sane.