Less than one month from today, on July 23 24*, Google will start prominently labeling any site loaded in Chrome without HTTPS as "Not Secure".
Check to see if your domain will be impacted:
When we wrote about Google’s plans back in February, the percent of sites loaded over HTTPS clocked in at 69.7%. Just one year prior to that only 52.5% of sites were loaded using SSL/TLS—the encryption protocol behind HTTPS—so tremendous progress has been made.
Unfortunately, quite a few popular sites on the web still don’t support HTTPS (or fail to redirect insecure requests) and will soon be flagged by Google. I spent some time scanning the top one million sites, and here’s what I learned about the 946,039 reachable over plaintext (unencrypted) HTTP:
Click image to enlarge
If you were to ask the operators of these sites why they don’t protect themselves and their visitors with HTTPS, the responses you’d get could be bucketed into the following three groups: "I don’t need it", "it’s difficult to do", or "it’s slow".
None of these are legitimate answers, but they’re common misconceptions so let’s take each in turn.
Myth #1: "HTTPS is difficult to deploy"
For Individual Sites
This was true.. in the mid 1990s, when I placed my first SSL certificate order. All that has changed.
Back then, I was a high school student writing software for my friend’s mom’s company. We were getting ready to launch her website and I learned that we needed something called an "SSL certificate" to transact securely online, but I had no idea how to get one.
After a bit of research conducted over my blazingly fast US Robotics Sportster 14.4k modem (we had recently upgraded from the relatively slow MultiTech 9600), I found out that we had to mail the company’s "original" Articles of Incorporation, emblazoned with the State Seal of Massachusetts and signed by company officers, along with a hefty check to some far away office. I asked her what to put for my title so she shrugged and said "CTO" as that sounded more official and likely to get us approved. A week or so later, the CA finally emailed the certificate.
Thankfully, we’ve come a long way since then. Today, you can protect your site with HTTPS in a matter of seconds, for free, either by signing up for Cloudflare or using a CA such as Let’s Encrypt. If you use Cloudflare we’ll renew your certificate automatically, and store it within milliseconds of your users for optimal performance, using our 150+ data centers around the world. As an added benefit, once we’re handling your SSL/TLS traffic, you can start using technologies like Cloudflare Workers to implement any logic you want at the edge.
For SaaS Providers
While the "it’s difficult" excuse rings hollow for individual site operators, things do get a bit more challenging when you’re dealing with issuing (and regularly renewing) hundreds, thousands, or even millions of certificates. Such is the case for SaaS providers who write and deploy software on another company’s domain, e.g., https://blog.example.com or https://mystore.example.
The reason that it can seem difficult to manage SSL certificates on behalf of other companies (putting aside performance and scale for a second), is that Certificate Authorities are only supposed to give out SSL certificates for hostnames where the requestor has "demonstrated control". Fortunately, methods such as HTTP-based validation, i.e., placing a random token on a well-defined path that the CA can access, have reduced the burden on the end-customer to a single step.
For those that want the benefits of having an edge provider like Cloudflare in front of their servers for acceleration and protection, our SSL for SaaS product reduces this process to a single API call. Alternatively, those that wish to to handle their own issuance, renewal, certificate hosting, and DDoS protection, the HTTP validation method or ACME protocol can be used.
Myth #2: "I don’t need HTTPS"
This argument is the most puzzling to me, especially when spouted by people who should know better. Even if you don’t care about performance—see myth #3 below—surely you care about the safety and privacy of those visiting your site.
Without HTTPS, anyone in the path between your visitor’s browser and your site or API can snoop on (or modify) your content without your consent. This includes governments, employers, and even especially internet service providers.
If you care about your users receiving your content unmodified and being safe from maliciously injected advertisements or malware, you care about—and must use—HTTPS.
Besides safety, there are additional benefits such as SEO and access to new web features: increasingly, the major browser vendors such as Apple, Google, Mozilla, and Microsoft, are restricting functionality to only work over HTTPS. As for mobile apps, Google will soon block unencrypted connections by default, in their upcoming version of Android. Apple also announced (and will soon hopefully follow through on their requirement) that apps must use HTTPS.
Myth #3: "HTTPS is slow"
Lastly, the other common myth about HTTPS is that it’s “slow”. This belief is a holdover from an era when SSL/TLS could actually have a negative performance impact on a site, but that's no longer the case today. In fact, HTTPS is required to enable and enjoy the performance benefits of HTTP/2.
Source: Is TLS Fast Yet? Click image to enlarge
Detractors typically think HTTPS is slow for two primary reasons: i) it takes marginally more CPU power to encrypt and decrypt data; and ii) establishing a TLS session takes two network round trips between the browser and the server.
Even with decade old hardware, SSL/TLS adds less than 1% of CPU load, as Adam Langley explained while debunking the HTTPS performance/cost myth. Today’s processors also come with instruction sets such as AES-NI, that help performance. Further, session resumption technologies reduce the TLS 1.2 overhead and TLS 1.3 aims to eliminate these round-trips entirely.
When HTTPS content is served from the edge, typically 10-20 milliseconds away from your users in the case of Cloudflare, SSL/TLS enabled sites are incredibly fast and performant. And even when they are not served from an edge provider it bears repeating that SSL/TLS is not a performance burden! There’s really no excuse not to use it.
Will my site show “Not Secure” on July 23 24*?
To help you determine if your site is ready for July 23 24*, we’ve built the handy widget shown at the top of the page. Simply type in your domain name (without explicitly specifying "http://" or "https://" to emulate what your visitors typically do) and hit enter.
Using a Cloudflare Worker, we’ll connect to your site and check to see if it’s redirected to a secure HTTPS link.
How can I avoid my site showing "Not Secure"?
If you'd like to avoid your website showing "Not Secure" in Chrome, all you need to do is obtain an SSL certificate and configure your site to redirect all traffic to HTTPS.
If you're using Cloudflare, we’ll take care of the SSL certificate order and renewal for you; take a look at Troy Hunt's excellent video "HTTPS Is Easy!" series here: https://httpsiseasy.com/. You should be sure to use the "Always use HTTPS" toggle to redirect HTTP visitors to HTTPS:
Advanced users should also consider using HSTS to instruct the browser to always load your content over HTTPS, saving it a round trip (and page load time) on subsequent requests. And by turning on Automatic HTTPS Rewrites, you can also rewrite any content that would normally be loaded over HTTP to use HTTPS (if available):
If you're trying to protect your customers' vanity domains that are pointed to your SaaS application, reach out and we can help you with this process.
Want to help us secure the web with HTTPS?
The team that manages HTTPS and SSL certificate issuance at Cloudflare is hiring, in both Engineering and Product Management. Check out our open positions here:
- Product Manager, SSL/TLS and Crypto
- Web Services Engineer
- Security Software Engineer
- Full Stack Engineer
If you have a worker you'd like to share, or want to check out workers from other Cloudflare users, visit the “Recipe Exchange” in the Workers section of the Cloudflare Community Forum.
* After this post was published Google pushed the release back one day, to the 24th.