Skip to content
Permalink
Browse files

Use 'Is URL trustworthy?' rather than whitelisting 'https' and 'wss'.

Based on the discussion in the public-webappsec thread starting at [1],
our face-to-face at [2], and our recent call at [3], this patch aligns
mixed content's checks with Secure Context's definition of potentially
trustworthy URLs.

Among other things, this means that `http://127.0.0.1/` will not be
considered mixed content when loaded in an otherwise secure page.

[1]: https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0044.html
[2]: https://www.w3.org/2016/05/16-webappsec-minutes.html#item05
[3]: https://www.w3.org/2016/07/13-webappsec-minutes.html#item05

Closes #4.
Obviates #5.
  • Loading branch information...
mikewest committed Jul 20, 2016
1 parent 2ed0d54 commit 349501cdaa4b4dc1e2a8aacb216ced58fd316165
Showing with 26 additions and 8 deletions.
  1. +26 −8 index.src.html
@@ -78,6 +78,7 @@ <h1>Mixed Content</h1>
text: request; url: concept-request
text: url; for: request; url: concept-request-url
text: response; url: concept-response
text: url; for: response; url: concept-response-url
text: network error; url: concept-network-error
text: opaque filtered response; url: concept-filtered-response-opaque
text: initiator; url: concept-request-initiator
@@ -264,10 +265,20 @@ <h2 id="terms">Key Concepts and Terminology</h2>
</dfn>
</dt>
<dd>
We know <i lang="la">a priori</i> that a request to a particular URL will
be strongly authenticated if the URL's <a for="url">scheme</a> is
"`https`" or "`wss`", as requests to those schemes will result in network
errors for unauthenticated responses.
We know <i lang="la">a priori</i> 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:

1. The algorithm defined in [[secure-contexts#is-url-trustworthy]]
returns "`Potentially Trustworthy`" when executed upon |url|
[[!SECURE-CONTEXTS]].

2. |url|'s <a for="url">scheme</a> is "`data`".

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.
</dd>

<dt>
@@ -276,9 +287,16 @@ <h2 id="terms">Key Concepts and Terminology</h2>
</dfn>
</dt>
<dd>
We know <i lang="la">a posteriori</i> that a <a>response</a> is
unauthenticated if its <a for="response">HTTPS state</a> is "`deprecated`"
or "`none`".
We know <i lang="la">a posteriori</i> that a <a>response</a>
(|response|) is unauthenticated if both of the following statements
are true:

1. |response|'s <a for="response">url</a> is <a><i lang="la">a
priori</i> authenticated</a>.

2. If |response|'s <a for="response">url</a>'s <a for="url">scheme</a>
is "`https`" or "`wss`", |response|'s <a for="response">HTTPS
state</a> is "`modern`".
</dd>

<dt><dfn export>embedding document</dfn></dt>
@@ -587,7 +605,7 @@ <h3 id="categorize-settings-object">
<code>http://evil.com</code>. In this case, the insecure request to
<code>evil.com</code> will be blocked, as <code>a.com</code> was loaded
over a secure connection, even though the framed <code>data:</code> URL
is not <a><i lang="la">a priori</i> authenticated</a>.
would not block mixed content if loaded in a top-level context.
</div>
</div>
</section>

0 comments on commit 349501c

Please sign in to comment.
You can’t perform that action at this time.