Unfortunately, as described in a previous blog post, this is only half of the problem. To make sure that a page is secure and can't be controlled or eavesdropped by third-parties, browsers must ensure that not only the page itself but also all its dependencies are loaded via secure channels. Page elements that don't fulfill this requirement are called mixed content and can either result in the entire page being reported as insecure or even completely blocked, thus breaking the page for the end user.

When we conceived the Automatic HTTPS Rewrites project, we aimed to automatically reduce the amount of mixed content on customers' web pages without breaking their websites and without any delay noticeable by end users while receiving a page that is being rewritten on the fly.

A naive way to do this would be to just rewrite http:// links to https:// or let browsers do that with Upgrade-Insecure-Requests directive.

Unfortunately, such approach is very fragile and unsafe unless you're sure that

1. Each single HTTP sub-resource is also available via HTTPS.

2. It's available at the exact same domain and path after protocol upgrade (more often than you might think that's not the case).

If either of these conditions is unmet, you end up rewriting resources to non-existing URLs and breaking important page dependencies.

Thus we decided to take a look at the existing solutions.

Many security aware people use the HTTPS Everywhere browser extension to avoid those kinds of issues. HTTPS Everywhere contains a well-maintained database from the Electronic Frontier Foundation that contains all sorts of mappings for popular websites that safely rewrite HTTP versions of resources to HTTPS only when it can be done without breaking the page.

However, most users are either not aware of it or are not even able to use it, for example, on mobile browsers.

CC BY 2.0 image by Jared Tarbell

So we decided to flip the model around. Instead of re-writing URLs in the browser, we would re-write them inside the CloudFlare reverse proxy. By taking advantage of the existing database on the server-side, website owners could turn it on and all their users would instantly benefit from HTTPS rewriting. The fact that it’s automatic is especially useful for websites with user-generated content where it's not trivial to find and fix all the cases of inserted insecure third-party content.

At our scale, we obviously couldn't use the existing JavaScript rewriter. The performance challenges for a browser extension which can find, match and cache rules lazily as a user opens websites, are very different from those of a CDN server that handles millions of requests per second. We usually don't get a chance to rewrite them before they hit the cache either, as many pages are dynamically generated on the origin server and go straight through us to the client.

That means, to take advantage of the database, we needed to learn how the existing implementation works and create our own in the form of a native library that could work without delays under our load. Let's do the same here.

HTTPS Everywhere rulesets can be found in src/chrome/content/rules folder of the official repository. They are organized as XML files, each for their own set of hosts (with few exclusions). This allows users with basic technical skills to write and contribute missing rules to the database on their own.

Each ruleset is an XML file of the following structure:

<ruleset name="example.org">
  <!-- Target domains -->
  <target host="*.example.org" />
 
  <!-- Exclusions -->
  <exclusion pattern="^http://example\.org/i-am-http-only" />
 
  <!-- Rewrite rules -->
  <rule from="^http://(www\.)?example\.org/" to="https://$1example.org/" />
</ruleset>

At the moment of writing, the HTTPS Everywhere database consists of ~22K such rulesets covering ~113K domain wildcards with ~32K rewrite rules and exclusions.

For performance reasons, we can't keep all those ruleset XMLs in memory, go through nodes, check each wildcard, perform replacements based on specific string format and so on. All that work would introduce significant delays in page processing and increase memory consumption on our servers. That's why we had to perform some compile-time tricks for each type of node to ensure that rewriting is smooth and fast for any user from the very first request.

Let's walk through those nodes and see what can be done in each specific case.

First of all, we get target elements which describe domain wildcards that current ruleset potentially covers.

<target host="*.example.org" />

If a wildcard is used, it can be either left-side or right-side.

Left-side wildcard like *.example.org covers any hostname which has example.org as a suffix - no matter how many subdomain levels you have.

Right-side wildcard like example.* covers only one level instead so that subdomains with the same beginning but one unexpected domain level are not accidentally caught. For example, the Google ruleset, among others, uses the google.* wildcard and it should match google.com, google.ru, google.es etc. but not google.mywebsite.com.

Note that a single host can be covered by several different rulesets as wildcards can overlap, so the rewriter should be given entire database in order to find a correct replacement. Still, matching hostname allows to instantly reduce all ~22,000 rulesets to only 3-5 which we can deal with more easily.

Matching wildcards at runtime one-by-one is, of course, possible, but very inefficient with ~113K domain wildcards (and, as we noted above, one domain can match several rulesets, so we can't even bail out early). We need to find a better way.

CC BY 2.0 image by vige

We use Ragel to build fast lexers in other pieces of our code. Ragel is a state machine compiler which takes grammars and actions described with its own syntax and generates source code in a given programming language as an output. We decided to use it here too and wrote a script that generates a Ragel grammar from our set of wildcards. In turn, Ragel converts it into C code of a state machine capable of going through characters of URLs, matching hosts and invoking custom handler on each found ruleset.

This leads us to another interesting problem. At the moment of writing among 113K domain wildcards we have 4.7K that have a left wildcard and less than 200 which have a right wildcard. Left wildcards are expensive in state machines (including regular expressions) as they cause DFA space explosion during compilation so Ragel got stuck for more than 10 minutes without giving any result - trying to analyze all the *. prefixes and merge all the possible states where they can go, resulting in a complex tree.

Instead, if we choose to look from the end of the host, we can significantly simplify the state tree (as only 200 wildcards need to be checked separately now instead of 4.7K), thus reducing compile time to less than 20 seconds.

Let's take an oversimplified example to understand the difference. Say, we have following target wildcards (3 left-wildcards against 1 right-wildcard and 1 simple host):

<target host="*.google.com" />
<target host="*.google.co.uk" />
<target host="*.google.es" />
<target host="google.*" />
<target host="google.com" />

If we build Ragel state machine directly from those:

%%{
    machine hosts;
 
    host_part = (alnum | [_\-])+;
 
    main := (
        any+ '.google.com' |
        any+ '.google.co.uk' |
        any+ '.google.es' |
        'google.' host_part |
        'google.com.ua'
    );
}%%

We will get the following state graph:

You can see that the graph is already pretty complex as each starting character, even g which is an explicit starting character of 'google.' and 'google.com' strings, still needs to simultaneously go also into any+ matches. Even when you have already parsed the google. part of the host name, it can still correctly match any of the given wildcards whether as google.google.com, google.google.co.uk, google.google.es, google.tech or google.com.ua. This already blows up the complexity of the state machine, and we only took an oversimplified example with three left wildcards here.

However, if we simply reverse each rule in order to feed the string starting from the end:

%%{
    machine hosts;
 
    host_part = (alnum | [_\-])+;
 
    main := (
        'moc.elgoog.' |
        'ku.oc.elgoog.' |
        'se.elgoog.' |
        host_part '.elgoog' |
        'au.moc.elgoog'
    );
}%%

we can get much simpler graph and, consequently, significantly reduced graph build and matching times:

So now, all that we need is to do is to go through the host part in the URL, stop on / right after and start the machine backwards from this point. There is no need to waste time with in-memory string reversal as Ragel provides the getkey instruction for custom data access expressions which we can use for accessing characters in reverse order after we match the ending slash.

Here is animation of the full process:

After we've matched the host name and found potentially applicable rulesets, we need to ensure that we're not rewriting URLs which are not available via HTTPS.

Exclusion elements serve exactly this goal.

<exclusion pattern="^http://(www\.)?google\.com/analytics/" />
<exclusion pattern="^http://(www\.)?google\.com/imgres/" />

The rewriter needs to test against all the exclusion patterns before applying any actual rules. Otherwise, paths that have issues or can't be served over HTTPS will be incorrectly rewritten and will potentially break the website.

We don't care about matched groups nor do we care even which particular regular expression was matched, so as an extra optimization, instead of going through them one-by-one, we merge all the exclusion patterns in the ruleset into one regular expression that can be internally optimized by a regexp engine.

For example, for the exclusions above we can create the following regular expression, common parts of which can be merged internally by a regexp engine:

(^http://(www\.)?google\.com/analytics/)|(^http://(www\.)?google\.com/imgres/)

After that, in our action we just need to call pcre_exec without a match data destination – we don't care about matched groups, but only about completion status. If a URL matches a regular expression, we bail out of this action as following rewrites shouldn't be applied. After this, Ragel will automatically call another matched action (another ruleset) on its own until one is found.

Finally, after we both matched the host name and ensured that our URL is not covered by any exclusion patterns, we can go to the actual rewrite rules.

These rules are presented as JavaScript regular expressions and replacement patterns. The rewriter matches the URL against each of those regular expressions as soon as a host matches and a URL is not an exclusion.

<rule from="^http://(\w{2})\.wikipedia\.org/wiki/" to="https://secure.wikimedia.org/wikipedia/$1/wiki/" />

As soon as a match is found, the replacement is performed and the search can be stopped. Note: while exclusions cover dangerous replacements, it's totally possible and valid for the URL to not match any of actual rules - in that case it should be just left intact.

After the previous steps we are usually reduced only to couple of rules, so unlike in the case with exclusions, we don't apply any clever merging techniques for them. It turned out to be easier to go through them one-by-one rather than create a regexp engine specifically optimized for the case of multi-regexp replacements.

However, we don't want to waste time on regexp analysis and compilation on our edge server. This requires extra time during initialization and memory for carrying unnecessary text sources of regular expressions around. PCRE allows regular expressions to be precompiled into its own format using pcre_compile. Then, we gather all these compiled regular expressions into one binary file and link it using ld --format=binary - a neat option that tells linker to attach any given binary file as a named data resource available to the application.

CC BY 2.0 image by DaveBleasdale

The second part of the rule is the replacement pattern which uses the simplest feature of JavaScript regex replacement - number-based groups and has the form of https://www.google.com.$1/ which means that the resulting string should be concatenation of "https://www.google.com." with the matched group at position 1, and a "/".

Once again, we don't want to waste time performing repetitive analysis looking for dollar signs and converting string indexes to numeric representation at runtime. Instead, it's more efficient to split this pattern at compile-time into { "https://www.google.com.", "/" } static substrings plus an array of indexes which need to be inserted in between - in our case just { 1 }. Then, at runtime, we simply build a string going through both arrays one-by-one and concatenating strings with found matches.

Finally, after such string is built, it's inserted in place of the previous attribute value and sent to the client.

Glad you asked.

The HTTPS Everywhere extension uses an automated checker that checks the validity of rewritten URLs on any change in ruleset. In order to do that, rulesets are required to contain special test elements that cover all the rewrite rules.

<test url="http://maps.google.com/" />

What we need to do on our side is to collect those test URLs, combined with our own auto-generated tests from wildcards, and to invoke both the HTTPS Everywhere built-in JavaScript rewriter and our own side-by-side to ensure that we're getting same results — URLs that should be left intact, are left intact with our implementation and URLs that are rewritten, are rewritten identically.

After all this was done and tested, we decided to look around for other potential sources of guaranteed rewrites to extend our database.

And one such is HSTS preload list maintained by Google and used by all the major browsers. This list allows website owners who want to ensure that their website is never loaded via http://, to submit their hosts (optionally together with subdomains) and this way opt-in to auto-rewrite of any http:// references to https:// by a modern browser before even hitting the origin.

This means, the origin guarantees that the HTTPS version will be always available and will serve just the same content as HTTP - otherwise any resources referenced from it will simply break as the browser won't attempt to fallback to HTTP after domain is in the list. A perfect match for another ruleset!

As we already have a working solution and don't have any complexities around regular expressions in this list, we can download the JSON version of it directly from the Chromium source and convert to the same XML ruleset with wildcards and exclusions that our system already understands and handles, as part of the build process.

This way, both databases are merged and work together, rewriting even more URLs on customer websites without any major changes to the code.

It was... but it's not really the end of the story. You see, in order to provide safe and fast rewrites for everyone, and after analyzing the alternatives, we decided to write a new streaming HTML5 parser that became the core of this feature. We intend to use it for even more tasks in future to ensure that we can improve security and performance of our customers websites in even more ways.

However, it deserves a separate blog post, so stay tuned.

And remember - if you're into web performance, security or just excited about the possibility of working on features that do not break millions of pages every second - we're hiring!

P.S. We are incredibly grateful to the folks at the EFF who created the HTTPS Everywhere extension and worked with us on this project.

Long ago it was difficult, expensive, and slow to set up an HTTPS capable web site. Then along came services like CloudFlare’s 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.

Boom.

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.

Unfortunately, the story doesn’t end there. Many otherwise secure sites suffer from the problem of mixed content. And mixed content means the green padlock icon will not be displayed for an https:// site because, in fact, it’s not truly secure.

Here’s the problem: if an https:// website includes any content from a site (even its own) served over http:// the green padlock can’t be displayed. That’s because resources like images, JavaScript, audio, video etc. included over http:// open up a security hole into the secure web site. A backdoor to trouble.

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.

Today, Google Chrome shows a circled i on any https:// that has insecure content.

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) to be served over HTTPS.

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

It's tempting, but naive, to think that the solution to mixed content is easy: “Simply load everything using https:// and just fix your website”. Unfortunately, the smörgåsbord of content loaded into modern websites from first-party and third-party web sites makes it very hard to ‘simply’ make that change.

CC BY 2.0 image by Mike Mozart

Wired documented their transition to https:// in a series of blog posts that shows just how hard it can be to switch everything to HTTPS. They started in April and spent 5 months on the process (after having already prepped for months just to get to https:// on their main web site). In May they wrote about a snag:

"[…] 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 “mixed content” 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—that we are delivering as much of WIRED.com’s content as securely possible.”

In 2014, the New York Times identified mixed content as a major hurdle to going secure:

"To successfully move to HTTPS, all requests to page assets need to be made over a secure channel. It’s a daunting challenge, and there are a lot of moving parts. We have to consider resources that are currently being loaded from insecure domains — everything from JavaScript to advertisement assets.”

And the W3C recognized this as a huge problem saying: “Most 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.” And cited the BBC’s huge archive as a difficult example.

But it’s not just media sites that have a problem with mixed content. Many CMS users find it difficult or impossible to update all the links that their CMS generates as they may be buried in configuration files, source code or databases. In addition, sites that need to deal with user-generated content also face a problem with http:// URIs.

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.

CC BY 2.0 image by Ben Tilley

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

Passive content is anything else: images, audio, video that are written into the page but that cannot themselves access the page.

Active content is a real threat because if an attacker manages to intercept the request for an http:// URI they can replace the content with their own. This is not a theoretical concern. In 2015 Github was attacked by a system dubbed the Great Cannon that intercepted requests for common JavaScript files over HTTP and replaced them with a JavaScript attack script. The Great Cannon weaponized innocent users’ machines by intercepting TCP and exploiting the inherent vulnerability in active content loaded from http:// URIs.

Passive content is a different kind of threat: because requests for passive content are sent in the clear an eavesdropper can monitor the requests and extract information. For example, a well positioned eavesdropper could monitor cookies, web pages visited and potentially authentication information.

The Firesheep Firefox add-on can be used to monitor a local network (for example, in a coffee shop) for requests sent over HTTP and automatically steal cookies allowing a user to hijack someone’s identity with a single click.

Today, modern browsers block active content that's loaded insecurely, but allow passive content through. Nevertheless, transitioning to all https:// is the only way to address all the security concerns of mixed content.

We’ve 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 ‘one click’ experience.

CC BY 2.0 image by Anthony Easton

We considered a number of approaches:

Automatically insert the upgrade-insecure-requests CSP directive

The upgrade-insecure-requests directive can be added in a Content Security Policy header like this:

Content-Security-Policy: upgrade-insecure-requests

which instructs the browser to automatically upgrade any HTTP request to HTTPS. This can be useful if the website owner knows that every subresource is available over HTTPS. The website will not have to actually change http:// URIs embedded in the website to https://, the browser will take care of that automatically.

Unfortunately, there is a large downside to upgrade-insecure-requests. Since the browser blindly upgrades every URI to https:// regardless of whether the resulting URI will actually work pages can be broken.

Modify all links to use https://

Since not all browsers used by visitors to CloudFlare web sites support upgrade-insecure-requests we considered upgrading all http:// URIs to https:// as pages pass through our service. Since we are able to parse and modify web pages in real-time we could have created an ‘upgrade-insecure-requests’ service that did not rely on browser support.

Unfortunately, that still suffers from the same problem of broken links when an http:// URI is transformed to https:// but the resource can’t actually be loaded using HTTPS

Modify links that point to other CloudFlare sites

Since CloudFlare gives all our 4 million customers free Universal SSL and we cover a large percentage of web traffic we considered just upgrading http:// to https:// for URIs that we know (because they use our service) will work.

This solves part of the problem but isn’t a good solution for the general problem of upgrading from HTTP to HTTPS

Create a system that rewrites known HTTPS capable URIs

Finally, we settled upon doing something smart: upgrade a URI from http:// to https:// if we know that the resource can be served using HTTPS. To figure out which links are upgradable we turned to the EFF’s excellent HTTPS Everywhere extension and Google Chrome HSTS preload list to augment our knowledge of CloudFlare sites that have SSL enabled.

We are very grateful that the EFF graciously accepted to help us with this project.

The HTTPS Everywhere ruleset goes far beyond just switching http:// to https://: it contains rules (and exclusions) that allow it (and us) to target very specific URIs. For example, here’s an actual HTTP Everywhere rule for gstatic.com:

<rule from="^http://(csi|encrypted-tbn\d|fonts|g0|[\w-]+\.metric|ssl|t\d)\.
gstatic\.com/" to="https://$1.gstatic.com/"/>

It uses a regular expression to identify specific subdomains of gstatic.com that can safely be upgraded to use HTTPS. The complete set of rules can be browsed here.

Because we need to upgrade a huge number of URIs embedded in web pages (we estimate around 5 million per second) we benchmarked existing HTML parsers (including our own) and decided to write a new one for this type of rewriting task. We’ll write more about its design, testing and performance in a future post.

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 ‘one click’:

We will be monitoring the performance and effectiveness of this feature and enable it by default for Free and Pro customers later in the year. We also plan to use the Content Security Policy reporting features to give customers an automatic view of which URIs remain to be upgraded so that their transition to all https:// is made as simple as possible: sometimes just finding which URIs need to be changed can be very hard as Wired found out.

Would love to hear how this feature works out for you.

Since CloudFlare’s inception, we have worked tirelessly to make encryption as simple and as accessible as possible. Over the last two years, we’ve made CloudFlare the easiest way to enable encryption for web properties and internet services. From the launch of Universal SSL, which gives HTTPS to millions of sites for free, to the Origin CA, which helps customers encrypt their origin servers, to the “No Browser Left Behind” initiative, which ensures that the encrypted Internet is available to everyone, CloudFlare has pushed to make Internet encryption better and more widespread.

This week we are introducing three features that will dramatically increase both the quality and the quantity of encryption on the Internet. We are are happy to introduce TLS 1.3, Automatic HTTPS Rewrites, and Opportunistic Encryption throughout this week. We consider strong encryption to be a right and fundamental to the growth of the Internet, so we’re making all three of these features available to all customers for free.

Every day this week there will be new technical content on this blog about these features. We're calling it Encryption Week.

HTTPS is the standard for web encryption. Services that support HTTPS use a protocol called TLS to encrypt and authenticate connections. This week, CloudFlare will be the first service on the internet to offer the latest version of the protocol, TLS 1.3. CloudFlare has been heavily involved in the development of the protocol, which is more secure and delivers tangible performance benefits over previous versions. Establishing an HTTPS connection with TLS 1.3 requires fewer messages than previous versions of TLS, making page load times noticeably faster, especially on mobile networks.

If it takes 50 miliseconds for a message to travel from the browser to CloudFlare, the speed boost from TLS 1.3 is enough to take sites that seem “sluggish” (over 300ms), and turn them into sites that load comfortably fast (under 300ms).

Comparison of TLS 1.2 and TLS 1.3 handshakes

TLS 1.3 is enabled in the developer releases of both Firefox and Chrome (Firefox Nightly and Chrome Canary), and all major browsers have committed to implementing the new protocol.

CloudFlare offers HTTPS to all customer sites through Universal SSL, but many sites don’t take advantage of it and continue to offer their sites over unencrypted HTTP. One of the main reasons sites don’t take advantage of HTTPS is because of so-called “mixed content.” This week we are launching Automatic HTTPS Rewrites, a feature that helps site owners address mixed content so they can safely upgrade to HTTPS.

A user requesting a web page over HTTPS can assume that the connection is authenticated, encrypted and that the response has not been tampered with. However, if any of the sub-resources (scripts, images) are requested over an insecure protocol such as HTTP, then those parts of the site can be accessed and modified by attackers. HTTPS sites with insecure sub-resources contain mixed content. Modern browsers will attempt to protect users from mixed content by providing warnings for passive content (such as images), and blocking insecure active content (scripts, stylesheets) from loading. Because of this, sites with mixed content often don’t work correctly.

Sites served with HTTP currently look “neutral” to visitors compared to HTTPS sites with mixed content, so site operators often prefer to serve their sites with insecure HTTP rather than partially-secured HTTPS. This is changing. Both Chrome and Firefox announced that they will begin to show increasingly negative indicators to visitors of HTTP sites. Chrome is planning to eventually put the words “Not Secure” in the address bar for HTTP sites, making it much less appealing for site operators to choose HTTP over HTTPS. Because of this, fixing mixed content and moving your site to HTTPS is more important than ever.

Some mixed content is not mixed content at all. Often, sub-resources are available over HTTPS, but the page’s source has been hardcoded to download them over HTTP. Manually changing “http” to “https” in the page’s source is often enough to fix mixed content in these cases. However, many sites can’t do that because their sites are created dynamically by content management systems or they include third party resources that they have no control over.

For Wordpress customers, we tackled this issue by modifying the CloudFlare Wordpress plugin to automatically rewrite insecure URLs. Building on the success of this approach, we decided to build URL rewriting functionality into CloudFlare itself. The result is a feature called Automatic HTTPS Rewrites, which we are making available to all customers for free this week.

CloudFlare customers with Automatic HTTPS Rewrites enabled on their site will have “http" replaced with “https” for all sub-resources that are also available over HTTPS. We use the EFF’s HTTPS Everywhere list, Chrome’s HSTS preload list, and soon our own internal list of HTTPS-enabled domains to determine whether sites can be upgraded. This feature facilitates the seamless upgrade of customer sites to HTTPS, allowing them to take full advantage of Universal SSL. As a bonus, Automatic HTTPS Rewrites also re-writes links from “http://” to “https://” whenever possible, ensuring that web visitors stay safe even when they leave your site.

CC 2.0 Generic Chris Applegate

Many sites can fix mixed content by changing “http” to “https,” but some sites can’t. This is often because they have sub-resources hosted on domains that don’t support HTTPS. One of the major causes of mixed content is advertising. Many ad exchanges still serve advertisements that contain references to insecure HTTP assets, making it hard for publishers and others that rely on advertising revenue to upgrade to HTTPS. These sites not only miss out on the many security and privacy benefits of serving their site over an encrypted connection, they also miss out on the performance benefits of HTTP/2, which is only available over encrypted connections.

Enter Opportunistic Encryption, a web feature that allows HTTP websites to be accessed over an encrypted HTTP/2 connection. With Opportunistic Encryption, CloudFlare adds a header to tell supporting browsers that the site is available over an encrypted connection. Opportunistic Encryption will be available to all customers later this week, for free.

For HTTP sites, Opportunistic Encryption can provide some (but not all) of the benefits of HTTPS. Connections secured with Opportunistic Encryption don’t get some HTTPS-only features such as the location API and the green lock icon. However, the connection is encrypted (and soon authenticated — we present a valid certificate and Firefox Nightly validates it), protecting data from passive snooping.

The big advantage provided by Opportunistic Encryption is HTTP/2, the new web protocol that can dramatically improve load times. HTTP/2 is unavailable over unencrypted connections. Visitors using browsers that support Opportunistic Encryption (currently only Firefox 38 and later) will be able to browse HTTP sites using HTTP/2 for the first time.

At CloudFlare we are dedicated to improving security and performance for our customers, and building a safer web with strong encryption built in by default. The three features we are introducing during Encryption Week will work in tandem to improve security and performance of all CloudFlare customers.

• All encrypted sites will gain faster connection times from TLS 1.3

• Sites that can be upgraded to HTTPS by Automatic HTTPS Rewrites will gain HTTPS

• Sites that can’t be upgraded to HTTPS will gain encryption and HTTP/2 from Opportunistic Encryption

One of our goals at CloudFlare is to put an end to the unencrypted Internet. These three features enable a faster internet while moving us closer to that goal.

As many are aware, CloudFlare launched Universal SSL several months ago. We saw lots of customers sign up and start using these new, free SSL certificates. For many customers that didn’t already have an SSL certificate, they were able to use “Flexible SSL”.

Flexible SSL creates a secure (HTTPS) connection between the website visitor and CloudFlare and then an in-secure (HTTP) connection between CloudFlare and the origin server. For any site using absolute links to assets (i.e. javascript, css, and image files), this can lead to a “Mixed Content” error.

What is “Mixed Content”? This can be understood as mixed protocol. When the webpage is loaded over SSL (HTTPS protocol), most browsers expect all of the assets to be loaded over the same protocol. Some browsers will display an error about loading “insecure content” while others will just block the insecure content outright.

This error only applies to pages loaded over SSL, since the browser is working to make sure that secure pages only load equally secure assets.

The latest version of the CloudFlare plugin for Wordpress works to resolve a lot of these errors by altering the protocol within the links to assets. Where currently your Wordpress site may link to your stylesheet like this:

http://www.example.com/wp/wp-content/themes/twentyfifteen/style.css?ver=4.1

We’ll remove the “http:” part to make this into a relative protocol:

//www.example.com/wp/wp-content/themes/twentyfifteen/style.css?ver=4.1

A further update to this rewriting doesn’t enable this rewriting for canonical URLs, since Google and other search engines expect this to be an absolute URL. Google also recommends securing your site with SSL, and being able to enable Flexible SSL is a great way to achieve this SEO boost!

A relative protocol //www.example.com tells your browser to load the asset over the same protocol as the main page. If your site loads over HTTPS, then the browser will try to load the asset over HTTPS as well. (In other words, NOT mixed. Everything is over HTTPS!)

This approach has no negative side effects for customers who don’t enable SSL (or who have traffic visit over HTTP as well as HTTPS), since if the page is loaded over HTTP, the assets will be loaded on the same protocol.

Protocol rewriting is on by default in our current version of the Wordpress plugin, so you should be able to enable Flexible SSL on your account and have traffic go to https://www.yourdomain.com.

CloudFlare recommends also adding a page rule for http://www.yourdomain.com* that redirects all traffic to HTTPS (assuming that Wordpress is set up for the WWW subdomain and isn’t within a directory on your domain).

With these two changes we can secure all traffic to your Wordpress site between the customer and CloudFlare’s server.

While this improvement should allow many Wordpress users to enable Flexible SSL without any other changes to their website, there are a few items to consider:

If after upgrading to the latest version of the Wordpress plugin, you still get “Mixed Content” errors, it’s likely that a plugin you are using adds assets to the site though javascript. The ways and methods to do this vary greatly, so it’s not currently possible to catch all of these instances. Plugin developers are encouraged to link to assets relatively or use Wordpress’s built-in methods for adding assets to the page.

It’s also important to note the limitation of Flexible SSL. For websites that collect credit cards and other secure information, it’s important to secure this information from the customer all the way to your server, so we recommend using Full SSL and having an SSL certificate on your server because this also secures the traffic between CloudFlare and your origin.