By David Strauss February 12, 2018
As of October 2017, sites without HTTPS are now flagged as “Not Secure” for sensitive pages in Chrome. This is the latest change Google has made to keep ratcheting up the penalties for website owners who do not secure their sites. This adds to an ever-longer list of key topics around HTTPS, including search ranking effects and how to optimize the performance of HTTPS.
Unfortunately, while adoption is accelerating, most websites have still not started transitioning to HTTPS, and many of the sites that have attempted to deploy HTTPS are misconfigured. To help website owners out, Google recently published a report on the root causes to browser warnings from 300M failure reports collected from Chrome telemetry.
Here are the top server-side HTTPS configuration errors Google identified:
-
Insufficient Intermediates: Gap in trust between Certificate Authority root installed in the browser/OS and the website certificate.
-
Invalid Authority or Untrusted Root: Self signed certificate or internal CA that is not trusted by the browser.
-
Name Mismatch: The certificate is for a different website domain.
-
Date Error: The certificate is expired.
-
Weak Signature Algorithm: At least one certificate relies on an insecure approach.
| Website Owner Duty | Browser Validation | Failure Case | Frequency |
|---|---|---|---|
| Include the intermediate cert in the webserver config. | Am I aware of the intermediate cert that is vouching for the website cert? | Insufficient Intermediates | 😒 😒 😒 😒 😒 |
| Use a broadly trusted CA. | Do I trust the root certificate that vouches for the intermediate cert? | Invalid Authority or Untrusted Root | 😒 😒 |
| Generate the CSR properly, including all necessary domain names. | Is the domain I’m accessing on the website certificate? | Name Mismatch | 😒 😒 😒 😒 |
| Renew and redeploy certificates before expiration | Is it before the expiration date on the website certificate? | Date Error | 😒 😒 |
| Choose a CA with modern security. | Does each certificate that vouches for another do so in a way that’s resistant to forgery? | Weak Signature Algorithm | 😒 |
| Ensure all content on an HTTPS page gets delivered with HTTPS | Is the HTTPS page only loading HTTPS resources? | Mixed-Mode Content | 😒 😒 😒 |
Our goal in this post is to explain how to avoid these errors by leveraging Pantheon’s Global CDN.
How HTTPS + TLS Work (in a Nutshell)
To understand why HTTPS can be broken, it’s necessary to understand how it works properly. Without delving into the details of the protocol, here’s what happens (for a standard domain control-validated certificate). The detailed steps of how this gets obtained, deployed, and used are below the diagram. For sites on Pantheon, this happens behind the scenes as part of our Global CDN.
Obtaining and Deploying the Certificate
-
The site owner creates a certificate signing request for the domain(s) for the website. A mistake here will cause name mismatch and date error (the latter if the requested start is after the current date or time).
-
A certificate authority (CA) validates that the certificate is being obtained by someone (or a service) with control of the domain. “Control” usually means DNS, HTTP, or even email for the domain going into the certificate. This CA must be trusted by the browsers of people visiting the website. An untrusted CA here will cause an “untrusted root” failure.
-
The CA signs the end entity (website) certificate using an intermediate certificate. For the CA, it’s like a lawyer signing a contract on their behalf: as long as there’s trust that the lawyer (intermediate certificate) is acting on behalf of the company (CA), it’s the same as if they did it themselves. If the proof isn’t generated in a modern way, it will cause a “weak signature algorithm” failure.
-
The server, load balancer, or CDN for the website gets the end entity (website) certificate and intermediate certificate added to the TLS configuration. The intermediate must be included to prove to browsers that the trust reaches all the way back to something the browser knows and trusts—a root certificate. Mistakes here will cause failures of types “insufficient intermediates” or “mixed-mode content.”
When a Browser Visits the Site
-
The web server, load balancer, or CDN cryptographically proves to the browser that it holds the domain control certificate. It also sends the intermediate certificate certificate.
-
The browser checks if there’s a valid trust from a root certificate to the intermediate certificate.
-
The browser checks if there’s a valid trust from the intermediate certificate to the end entity (website) certificate.
-
The browser checks that the certificate is valid for the domain being accessed.
-
The browser checks that the certificate is valid for the current date and time.
The Top Six HTTPS Configuration Errors
#1) Insufficient Intermediates
Frequency: Very common on mobile devices. Google reports that this causes 36% of validation issues on Android devices. It causes up to 5% of validation errors on some desktop environments. Because macOS shows the most issues on desktop environments, iOS (which isn’t included in Google’s data) is likely to have widespread issues, too, as it uses the same trusted certificates as macOS.
Root cause: This is a breakdown in browser step “C” above, but the cause is misconfiguration in deployment step “4.” Sometimes, the administration may have saved the correct intermediate to the server, but it still won’t be properly used; this is because some TLS implementations expect end entity (website) certificates and intermediates be be in the same file but in a particular order.
Mitigations: Browsers can sometimes work around this by shipping with popular intermediate certificate or even finding and obtaining them realtime if they’re missing but available from a well-known source. Relying on this is a bad practice, though, as it will cause many devices—particularly mobile devices—to fail to connect. At best, the browser will spend extra time fetching the missing intermediate, slowing the page load time.
Testing: Don’t simply pull up your site in a browser or two. As explained in “mitigating factors,” some browsers will mask this issue, but some releases of Chrome (older ones on Android) and Firefox (all versions) won’t. To avoid missing this common mistake, use the SSL Labs testing tool, which will show missing intermediate certificates and help you obtain/configure them.
Pantheon’s answer: Automatically and correctly handled. Pantheon’s Global CDN has the necessary intermediates configured and delivered to fully pass SSL Labs validation and work in almost all devices and browsers.
#2) Invalid Authority or Untrusted Root
Frequency: Somewhat common. This represents about 6-8% of validation errors across desktop and mobile environments. (This percentage combines invalid and untrusted authority numbers from the report.)
Root cause: This is a breakdown in validation step “B” caused by using a self-signed certificate or an inappropriate choice of certificate authority (CA) in step “2.” More rarely, a CA will have their trust revoked. Other times, an institutional or internal CA is inappropriately used for an externally facing site.
Mitigations: None. This configuration will almost never work.
Testing: While using a browser or two will almost always reveal this issue, running the SSL Labs test is more comprehensive, particularly if the certificate relies on cross-signing to support older OS releases and browsers.
Pantheon’s answer: Automatically and correctly handled. Our Global CDN infrastructure relies on Let’s Encrypt, which is broadly trusted by devices and browsers through a combination of direct and cross-signed trusts.
#3) Name Mismatch
Frequency: Common. About 10% of validation errors across most platforms.
Root Cause: This is a breakdown in validation step “D.” The root cause is an incorrect— often, incomplete—request created in step “1.”
Mitigations: None. This mistake will almost never work. Sometimes, a site will see partial failures if the certificate has the bare domain (example.com) but not the primary domain (www.example.com), or vice versa.
Testing: Use any browser or the SSL Labs test.
Pantheon’s answer: Automatically and correctly handled, as long as the site’s DNS is configured as instructed (and analyzed) by the Pantheon dashboard and HTTPS is marked as provisioned.
#4) Date Error
Frequency: Less common. Causes about 3-4% of failed validations.
Root cause: Usually caused by the certificate being expired. More rarely caused by the certificate not being valid yet (mostly on extremely new certificates).
Mitigations: None, but browsers seem to panic less when the certificate is merely expired.
Testing: As long as your device’s clock is accurate, just visit the site. SSL Labs can also check this.
Pantheon’s answer: Pantheon’s Global CDN automatically handles renewals and only deploys certificates that are already valid.
#5) Weak Signature Algorithm
Frequency: Harder to tell because the report didn’t automatically flag this in the overall dataset, but it appeared for 10% of sites in a small, random sampling of the unclassified validation failures.
Root cause: A signature in the chain of trust using a weak algorithm like SHA-1 (not great) or MD5 (totally untrustworthy).
Mitigations: None. Browsers that distrust weak signatures won’t trust the certificate.
Testing: Browsers vary in the algorithms they’ll accept. It’s best to review the SSL Labs report for this one.
Pantheon’s answer: All certificates issued for Global CDN use strong signature algorithms.
#6) Mixed-Mode Content
Frequency: Not covered by Google’s report, but seen frequently by Pantheon’s customer success team on sites migrating to the platform.
Root cause: Delivering the main page over HTTPS but including content (CSS, JS, images, often from other services like Disqus) via an HTTP URL. Often, the cause is incorrect detection of the URL scheme (HTTP vs. HTTPS) by the content management system (CMS). The broken detection usually comes from incorrect load balancer or CDN integration with how the CMS performs its detection.
Mitigations: Most browsers no longer block access to the site just because of mixed-mode content, but they won’t show a secure connection, either. Adding HSTS to the site can fix mixed-mode resources coming from the same domain as the web page.
Testing: Visit the site from a browser. If the site loads different content (say, responsively) for different device types, it may be necessary to test each variation.
Pantheon’s answer: We’ve integrated detection of the end-user browser’s URL scheme from Global CDN all the way to PHP. The standard checks done by Drupal and WordPress yield correct URLs without further configuration. We also have a guide for making the transition to pure HTTPS and avoiding this issue.
Who Gets HTTPS Wrong?
Surprisingly, the most frequent validation error reports come from large, institutional categories: government, education, and webmail services. Together, those categories comprise 77 of the 100 sites with the most frequently reported validation errors.
Because sites seeing frequent visits from Chrome users generate more reports, we shouldn’t assume small sites are more likely to get HTTPS right, just that most user pain comes from visiting institutional websites. It also means, no matter how large you are, that you’re not immune from subtle (but impactful) problems when deploying HTTPS.
The widespread mistakes seen on the server side for HTTPS—at organizations of all sizes—are why Pantheon’s Global CDN relies on platform-managed certificates. When there’s less that can go wrong, launching and maintaining sites is less error-prone. Global CDN also goes beyond getting the basics right; any Pantheon site can get the top grade (A+) from SSL Labs with just a couple steps.
Credit Where It’s Due
We’d like to thank Google, Leibniz University Hannover, Purdue University, and the International Institute of Information Technology Hyderabad for preparing such a comprehensive and actionable report on the challenges facing HTTPS today.
You may also like:
Topics: Drupal Hosting, Security, Speed & Performance, Website Technology, WordPress Hosting
