Encryption Week

Note: Since this was published we have renamed Encryption Week to Crypto Week. You can find this post, and news from Encryption and SSL weeks here.

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.

Automatic HTTPS Rewrites: Fixing mixed content automatically

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.