{"id":6074,"date":"2019-06-12T21:26:13","date_gmt":"2019-06-12T21:26:13","guid":{"rendered":"https:\/\/gtechbooster.com\/?p=6074"},"modified":"2026-01-03T15:27:36","modified_gmt":"2026-01-03T15:27:36","slug":"securing-the-internet","status":"publish","type":"post","link":"https:\/\/gtechbooster.com\/securing-the-internet\/","title":{"rendered":"Securing the internet"},"content":{"rendered":"\n

Privacy and security has justified a cause to bring encryption to an internet which was built without a foundation for security with an aims to put an end to the unencrypted Internet. But the web has a chicken and egg problem moving to HTTPS.<\/p>\n\n\n\n

\"\"<\/a><\/div><\/div>

Long ago it was difficult, expensive, and slow to set up an HTTPS capable web site. Then along came services like CloudFlare\u2019s Universal SSL that made switching from http:\/\/ to https:\/\/ as easy as clicking a button. With one click a site was served over HTTPS with a freshly minted, free SSL certificate.<\/p>\n\n\n\n

Boom.<\/p>\n\n\n\n

Suddenly, the website is available over HTTPS, and, even better, the website gets faster because it can take advantage of the latest web protocol HTTP\/2.<\/p>\n\n\n\n

Unfortunately, the story doesn\u2019t end there. Many otherwise secure \nsites suffer from the problem of mixed content. And mixed content means\n the green padlock icon will not be displayed for an https:\/\/ site \nbecause, in fact, it\u2019s not truly secure.<\/p>\n\n\n\n

Here\u2019s the problem: if an https:\/\/ website includes any content from a\n site (even its own) served over http:\/\/ the green padlock can\u2019t be \ndisplayed. That\u2019s because resources like images, JavaScript, audio, \nvideo etc. included over http:\/\/ open up a security hole into the secure\n web site. A backdoor to trouble.<\/p>\n\n\n\n

Web browsers have known this was a problem for a long, long time. Way back in 1997, Internet Explorer 3.0.2 warned users of sites with mixed content with the following dialog box.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Today, Google Chrome shows a circled i on any https:\/\/ that has insecure content. <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

And Firefox shows a padlock with a warning symbol. To get a green padlock from either of these browsers requires every single subresource (resource loaded by a page) has to be served over HTTPS. <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

If you had clicked Yes back in 1997, Internet Explorer would have \nignored the dangers of mixed content and gone ahead and loaded \nsubresources using plaintext HTTP. Clicking No prevented them from being\n loaded (often resulting in a broken but secure web page).<\/p>\n\n\n\n

Transitioning to fully secure content<\/h2>\n\n\n\n

It’s tempting, but naive, to think that the solution to mixed content is easy: \u201cSimply load everything using https:\/\/ and just fix your website\u201d. Unfortunately, the sm\u00f6rg\u00e5sbord of content loaded into modern websites from first-party and third-party web sites makes it very hard to \u2018simply\u2019 make that change.<\/p>\n\n\n\n

“[\u2026] one of the biggest challenges of moving to HTTPS is preparing all of our content to be delivered over secure connections. If a page is loaded over HTTPS, all other assets (like images and Javascript files) must also be loaded over HTTPS. We are seeing a high volume of reports of these \u201cmixed content\u201d issues, or events in which an insecure, HTTP asset is loaded in the context of a secure, HTTPS page. To do our rollout right, we need to ensure that we have fewer mixed content issues\u2014that we are delivering as much of WIRED.com\u2019s content as securely possible.\u201d<\/em><\/p><\/blockquote>\n\n\n\n

In 2014, the New York Times identified mixed content as a major hurdle<\/a> to going secure:<\/p>\n\n\n\n

“To successfully move to HTTPS, all requests to page assets need to be made over a secure channel. It\u2019s a daunting challenge, and there are a lot of moving parts. We have to consider resources that are currently being loaded from insecure domains \u2014 everything from JavaScript to advertisement assets.\u201d<\/em><\/p><\/blockquote>\n\n\n\n

And the W3C recognized<\/a> this as a huge problem saying: <\/p>\n\n\n\n

\u201cMost notably, mixed content checking has the potential to cause real headache for administrators tasked with moving substantial amounts of legacy content onto HTTPS. In particular, going through old content and rewriting resource URLs manually is a huge undertaking.\u201d<\/em> <\/p><\/blockquote>\n\n\n\n

And cited the BBC\u2019s huge archive<\/a> as a difficult example.<\/p>\n\n\n\n

But it\u2019s not just media sites that have a problem with mixed content.\n Many CMS users find it difficult or impossible to update all the links \nthat their CMS generates as they may be buried in configuration files, \nsource code or databases. In addition, sites that need to deal with \nuser-generated content also face a problem with http:\/\/ URIs.<\/p>\n\n\n\n

The Dangers of Mixed Content<\/h3>\n\n\n\n

Mixed content comes in two flavors: active and passive. Modern web browsers approach the dangers from these different types of mixed content as follows: active mixed content (the most dangerous) is automatically and completely blocked, passive mixed content is allowed through but results in a warning.<\/p>\n\n\n\n

\"\"
<\/strong>CC BY 2.0<\/strong><\/a> <\/strong>image<\/strong><\/a> by <\/strong>Ben Tilley<\/strong><\/a> <\/figcaption><\/figure><\/div>\n\n\n\n

Active content is anything that can modify the DOM (the web page itself). Resources included via the <script><\/code>, <link><\/code>, <iframe><\/code> or <object><\/code> tags, CSS values that use url<\/code> and anything requested using XMLHTTPRequest<\/code> is capable of modifying a page, reading cookies and accessing user credentials.<\/p>\n\n\n\n

Passive content is anything else: images, audio, video that are \nwritten into the page but that cannot themselves access the page.<\/p>\n\n\n\n

Active content is a real threat because if an attacker manages to \nintercept the request for an http:\/\/ URI they can replace the content \nwith their own. This is not a theoretical concern. In 2015 Github was \nattacked by a system dubbed the Great Cannon<\/a>\n that intercepted requests for common JavaScript files over HTTP and \nreplaced them with a JavaScript attack script. The Great Cannon \nweaponized innocent users\u2019 machines by intercepting TCP and exploiting \nthe inherent vulnerability in active content loaded from http:\/\/ URIs.<\/p>\n\n\n\n

Passive content is a different kind of threat: because requests for \npassive content are sent in the clear an eavesdropper can monitor the \nrequests and extract information. For example, a well positioned \neavesdropper could monitor cookies, web pages visited and potentially \nauthentication information.<\/p>\n\n\n\n

The Firesheep<\/a>\n Firefox add-on can be used to monitor a local network (for example, in a\n coffee shop) for requests sent over HTTP and automatically steal \ncookies allowing a user to hijack someone\u2019s identity with a single \nclick.<\/p>

\"\"<\/a><\/div><\/div>\n\n\n\n

Today, modern browsers block active content that’s loaded insecurely,\n but allow passive content through. Nevertheless, transitioning to all \nhttps:\/\/ is the only way to address all the security concerns of mixed \ncontent.<\/p>\n\n\n\n

Fixing Mixed Content Automatically<\/h3>\n\n\n\n

We\u2019ve wanted to help fix the mixed content properly for a long time as our goal is that the web become completely encrypted. And, like other CloudFlare services, we wanted to make this a \u2018one click\u2019 experience.<\/p>\n\n\n\n

We considered a number of approaches:<\/p>\n\n\n\n

Automatically insert the upgrade-insecure-requests CSP directive<\/em><\/p>\n\n\n\n

The upgrade-insecure-requests<\/a> directive can be added in a Content Security Policy<\/a> header like this:<\/p>\n\n\n\n

Content-Security-Policy: upgrade-insecure-requests\n<\/code><\/pre>\n\n\n\n
which instructs the browser to automatically upgrade any HTTP request\n to HTTPS. This can be useful if the website owner knows that every \nsubresource is available over HTTPS. The website will not have to \nactually change http:\/\/ URIs embedded in the website to https:\/\/, the \nbrowser will take care of that automatically.<\/p>\n\n\n\n
Unfortunately, there is a large downside to \nupgrade-insecure-requests. Since the browser blindly upgrades every URI \nto https:\/\/ regardless of whether the resulting URI will actually work \npages can be broken<\/a>.<\/p>\n\n\n\n
Modify all links to use https:\/\/<\/em><\/p>\n\n\n\n
Since not all browsers used by visitors to CloudFlare web sites \nsupport upgrade-insecure-requests we considered upgrading all http:\/\/ \nURIs to https:\/\/ as pages pass through our service. Since we are able to\n parse and modify web pages in real-time we could have created an \n\u2018upgrade-insecure-requests\u2019 service that did not rely on browser \nsupport.<\/p>\n\n\n\n
Unfortunately, that still suffers from the same problem of broken \nlinks when an http:\/\/ URI is transformed to https:\/\/ but the resource \ncan\u2019t actually be loaded using HTTPS<\/p>\n\n\n\n
Modify links that point to other CloudFlare sites<\/em><\/p>\n\n\n\n
Since CloudFlare gives all our 4 million customers free Universal SSL<\/span>\n and we cover a large percentage of web traffic we considered just \nupgrading http:\/\/ to https:\/\/ for URIs that we know (because they use \nour service) will work.<\/p>\n\n\n\n
This solves part of the problem but isn\u2019t a good solution for the general problem of upgrading from HTTP to HTTPS<\/p>\n\n\n\n
Create a system that rewrites known HTTPS capable URIs<\/em><\/p>\n\n\n\n
Finally, we settled upon doing something smart: upgrade a URI from \nhttp:\/\/ to https:\/\/ if we know that the resource can be served using \nHTTPS. To figure out which links are upgradable we turned to the EFF\u2019s \nexcellent HTTPS Everywhere<\/a> extension and Google Chrome HSTS preload<\/a> list to augment our knowledge of CloudFlare sites that have SSL enabled.<\/p>\n\n\n\n
We are very grateful that the EFF graciously accepted to help us with this project.<\/p>\n\n\n\n
The HTTPS Everywhere ruleset goes far beyond just switching http:\/\/ \nto https:\/\/: it contains rules (and exclusions) that allow it (and us) \nto target very specific URIs. For example, here\u2019s an actual HTTP \nEverywhere rule for gstatic.com:<\/p>\n\n\n\n
<rule from=\"^http:\/\/(csi|encrypted-tbn\\d|fonts|g0|[\\w-]+\\.metric|ssl|t\\d)\\.\ngstatic\\.com\/\" to=\"https:\/\/$1.gstatic.com\/\"\/>\n<\/code><\/pre>\n\n\n\n
It uses a regular expression to identify specific subdomains of \ngstatic.com that can safely be upgraded to use HTTPS. The complete set \nof rules can be browsed here<\/a>.<\/p>\n\n\n\n
Because we need to upgrade a huge number of URIs embedded in web \npages (we estimate around 5 million per second) we benchmarked existing \nHTML parsers (including our own) and decided to write a new one for this\n type of rewriting task. We\u2019ll write more about its design, testing and \nperformance in a future post.<\/p>\n\n\n\n
Automatic HTTPS Rewrites<\/h3>\n\n\n\n
Automatic HTTPS Rewrites are now available in the customer dashboard  for all CloudFlare customers. Today, this feature is disabled by default  and can be enabled in \u2018one click\u2019:<\/p>\n\n\n\n
We will be monitoring the performance and effectiveness of this \nfeature and enable it by default for Free and Pro customers later in the\n year. We also plan to use the Content Security Policy reporting \nfeatures to give customers an automatic view of which URIs remain to be \nupgraded so that their transition to all https:\/\/ is made as simple as \npossible: sometimes just finding which URIs need to be changed can be \nvery hard as Wired found out<\/a>.<\/p>\n\n\n\n
More Information<\/h2>\n\n\n\n