Chrome 43 Should Help Batten Down HTTPS Sites

River Tam writes The next version of Chrome, Chrome 43, promises to take out some of the work website owners — such as news publishers — would have to do if they were to enable HTTPS. The feature might be helpful for publishers migrating legacy HTTP web content to HTTPS when that old content can't or is difficult to be modified. The issue crops up when a new HTTPS page includes a resource, like an image, from an HTTP URL. That insecure resource will cause Chrome to flag an 'mixed-content warning' in the form of a yellow triangle over the padlock.

Comments

The first paragraph of TFA ...

[John Bokma]

Gives a better summary "The next version of Chrome will include a new security policy that may make it easier for developers to ensure “HTTPS” websites aren’t undermined by insecure HTTP resources."

Summary misses out the actual feature...

[NoNeeeed]

What a shock, a slashdot summary that misses the actual salient point of the linked article...

Here's the description of the new feature from the linked article:

If the same site was accessed in Chrome 43 -- which is beta now but should be stable in May -- the warning should vanish thanks to a browser Content Security Policy directive known as Upgrade Insecure Resources. The directive “causes Chrome to upgrade insecure resource requests to HTTPS before fetching them”, Google explained today.

Here's Google's own description of the feature from the Chromium Blog:

Upgrading legacy sites to HTTPS

Transitioning large collections of unmodifiable legacy web content to encrypted, authenticated HTTPS connections can be challenging as the content frequently includes links to insecure resources, triggering mixed content warnings. This release includes a new CSP directive, upgrade-insecure-resources, that causes Chrome to upgrade insecure resource requests to HTTPS before fetching them. This change allows developers to serve their hard-to-update legacy content via HTTPS more easily, improving security for their users.

So basically this means you don't have to worry if you accidentally miss an HTTP asset link on your site when upgrading to HTTPS, Chrome will automatically do that for you.

Hopefully the other browsers will follow suit soon, otherwise it's of limited use.

Re:Hello

[Anonymous Coward]

Nice try, but this is significantly different from what Firefox does.

From TFA:

The directive “causes Chrome to upgrade insecure resource requests to HTTPS before fetching them”, Google explained today.

TFA's link to chromium.org essentially says the exact same thing:

Upgrading legacy sites to HTTPS
Transitioning large collections of unmodifiable legacy web content to encrypted, authenticated HTTPS connections can be challenging as the content frequently includes links to insecure resources, triggering mixed content warnings. This release includes a new CSP directive, upgrade-insecure-resources, that causes Chrome to upgrade insecure resource requests to HTTPS before fetching them. This change allows developers to serve their hard-to-update legacy content via HTTPS more easily, improving security for their users.

Converting to plain English: If the URL says "http://", Chrome will first try the same link with "https://". You'll only see a mixed-content warning if the website fails to return content for the "https://" link. This obviously assumes that the website is running both HTTP and HTTPS, and that it will give the same content regardless of whether you use HTTP or HTTPS.

Your link to Firefox 23 only talks about issuing warnings for mixed content; it does not say anywhere that it attempts to retrieve the HTTPS version of an HTTP link.

tl;dr: Firefox just blocks it; Chrome looks for a safe alternative and only blocks if the safe alternative doesn't exist.

[ Disclaimer: I use Firefox; I have never used Chrome. ]

Re:Where's the rest of the summary?

[petermgreen]

The summary is that they are introducing a new http header, this can be used to tell the browser to automatically use https instead of http to request resources used by the page. Thus avoiding "mixed content" warnings without requiring the website operator to go through the whole page (and potentially things like stylesheets referenced by the page) changing urls to https.