SSL Dealing with mix content warnings in SSL - CSP upgrade-insecure-requests

eva2000 · Aug 27, 2015

Came across this while watching Letsencrypt video for a way of dealing with mixed content warnings if you have deployed a https SSL web site but have some page elements still loading from http. It's an additional header for Content-Security-Policy: upgrade-insecure-requests outlined at Upgrade Insecure Requests

1.2. Examples
Megacorp, Inc. wishes to migrate Example Domain to Example Domain They set up their servers to make their own resources available over HTTPS, and work with partners in order to make third-party widgets available securely as well.
They quickly realize, however, that the majority of their content is locked up in a database tied to an old content management system, and it contains hardcoded links to insecure resources (e.g., http:// URLs to images and other content). Unfortunately, it’s a substantial amount of work to update it.

As a stopgap measure, Megacorp injects the following header field into every HTML response that goes out from their servers:

Content-Security-Policy: upgrade-insecure-requests

This automatically upgrades all insecure resource requests from their pages to secure variants, allowing a user agent to treat the following HTML code:

<img src="http://example.com/image.png">
<img src="http://not-example.com/image.png">

as though it had been delivered as:

<img src="https://example.com/image.png">
<img src="https://not-example.com/image.png">

The URL will be rewritten before the request is made, meaning that no insecure requests will hit the network. Users will be safer, and Megacorp’s administrators will be happier, as all subresource requests will be transparently upgraded with no effort on their part.
Click to expand...

3.1. The upgrade-insecure-requests Content Security Policy directive
A server MAY instruct a user agent to upgrade insecure requests for a particular protected resource by sending aContent-Security-Policy header [CSP] that contains a upgrade-insecure-requests directive, defined via the following ABNF grammar:

directive-name = "upgrade-insecure-requests"
directive-value = ""

When enforcing the upgrade-insecure-requests directive:

Let settings be the protected resource’s incumbent settings object.

Set setting’s insecure requests policy to Upgrade.

Let tuple be a tuple of the protected resource’s URL's host and port.

Insert tuple into settings’s upgrade insecure navigations set.

Monitoring the upgrade-insecure-requests directive has no effect: the directive is ignored when sent via aContent-Security-Policy-Report-Only header. Authors can determine whether or not upgraded resources' original URLs were insecure via Content-Security-Policy-Report-Only. For example, Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint. See §3.4 Reporting Upgrades for additional detail.

In a thread on public-webappsec@, Peter Eckersley suggested modifying this to allow whitelisting specific hosts, rather than upgrading everything: "That way, if you have N third parties on a site, and (say) two of them provide images only, and don’t support HTTPS at all, you can use the upgrade mechanism for scripts on the other N - 2 origins." <https://github.com/w3c/webappsec/issues/184>

3.1.1. Relation to "Mixed Content"
The upgrade-insecure-requests directive results in requests being rewritten at the top of the Fetching algorithm[FETCH], as specified in §4.1 Upgrade request to a potentially secure URL, if appropriate . It’s important to note that the rewrite happens before either Mixed Content [MIX] or Content Security Policy checks take effect [CSP2].

This ordering means that upgraded requests will not be flagged as mixed content. Moreover, it means thatupgrade-insecure-requests’s effect takes place before the block-all-mixed-content directive would have a chance to block the request. If the former is set, the latter is effectively a no-op.

We recommend that authors set one directive or the other, as outlined in §1.3 Recommendations.
Click to expand...

eva2000 · Aug 27, 2015

1.3. Recommendations

We recommend that authors who wish to ensure that user agents which support upgrade-insecure-requests are as secure as possible do the following:
Redirect a priori insecure, safely upgradable requests from HTTP to HTTPS by responding with aLocation header and a 307 status code.
In Nginx, this kind of redirection might look like this:
Code:
server {
  if ($http_upgrade_insecure_requests = "1") {
    add_header Vary Upgrade-Insecure-Requests;
    return 307 https://$host$request_uri;
  }
}
This is, of course, greatly simplified; your configuration will likely be significantly more complex.
Respond to potentially secure safely upgradable requests with a upgrade-insecure-requests directive if necessary for the resource being requested.
In Nginx, adding this directive might look like this:
Code:
server {
  ...

  add_header Content-Security-Policy upgrade-insecure-requests;

  ...
}
This is, of course, greatly simplified; your configuration will likely be significantly more complex.
If the origin is HSTS-safe, then protect against SSL-stripping man-in-the-middle attacks by sending aStrict-Transport-Security header with the preload directive, and ensure that insecure content is never loaded by enabling Mixed Content’s strict mode.
In Nginx, adding this header might look like this (note the use of the preloaded directive, which signifies that this origin’s HSTS state can be safely imported into user agents' HSTS preload lists):
Code:
server {
  ...
  add_header Strict-Transport-Security "max-age=10886400; preload"
  add_header Content-Security-Policy block-all-mixed-content;

  ...
}
This is, of course, greatly simplified; your configuration will likely be significantly more complex.

Additionally, work with user agent vendors to add the origin to HSTS Preload Lists (for example, by submitting the origin to hstspreload.appspot.com).
If the origin is conditionally HSTS-safe, then opt-into HSTS only in response to safely upgradable requests.
In Nginx, adding this header conditionally might look like this (note the use of map, as setting headers inside if without returning immediately is, well, iffy):
Code:
server {
  ...

  map $http_https $sts {
    "1" "max-age=10886400"
  }
  add_header Strict-Transport-Security $sts;

  ...
}
This is, of course, greatly simplified; your configuration will likely be significantly more complex.
Click to expand...

eva2000 · Aug 27, 2015

Upgrade insecure requests - Chrome Platform Status

CSP Policy Directives - Web security | MDN

Implementation Status for CSP upgrade-insecure-requests

Enabled by default in desktop Chrome 43 (launch bug)

Available in Chrome for Android release 43.

Available in Android WebView release 43.

eva2000 · Oct 22, 2015

Web browser support process for CSP Upgrade Insecure Requests Can I use... Support tables for HTML5, CSS3, etc

Log in / Register

Forums

Want to subscribe to topics you're interested in?

SSL Dealing with mix content warnings in SSL - CSP upgrade-insecure-requests

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Want to subscribe to topics you're interested in?

SSL Dealing with mix content warnings in SSL - CSP upgrade-insecure-requests

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.