HTTPS Everywhere: Remove Mixed Content To Improve SEO

Introduction

In recent years we have seen the Web and the assortment of industries that drive it (i.e. browsers, search engines, etc.) starting to take user security more seriously. Chrome is now warning users against HTTP websites with more browsers ready to follow, while Google Search has confirmed that they give search engine ranking boosts to HTTPS websites.

Developments such as these have motivated a significant portion of website owners to move their servers away from old, insecure HTTP to the more secure alternative HTTPS. (HTTPS is considered more secure because it requires servers to be authenticated via SSL certificates as a means to protect users from most types of network attacks.)

However, the majority of websites have only implemented HTTPS for their most critical components, such as log-in or POST requests, but may still use HTTP for other “non-critical” functions.

This made sense in the early days of HTTPS, since encrypted connections are more computationally expensive due to having to perform handshakes for every new connection. Furthermore, at that time many widely-used web development platforms, libraries and environments were not HTTPS-ready – a fact which caused administrators and developers unending headaches in the form of late-night application crashes or obscure run-time errors.

Of course, this is not true anymore – in fact, as this article will argue, not using HTTPS for all your website’s connections is actually bad for your business.

Mixed content

Websites that don’t serve all their content over HTTPS are called mixed content websites. An academic paper published in 2015 found that over 43% of their sample of Alexa’s top 100,000 served at least one type of mixed content.

Although this doesn’t sound like a big deal, mixed content can be quite dangerous for users, but it can also have negative effects on websites as well.

Security issues

The most important reason to use HTTPS for your entire website is security. A single unprotected HTTP connection is all hackers need. Man-in-the-middle (MITM) attackers can replace any HTTP content on your page in order to steal credentials and sessions, acquire sensitive data, or launch browser exploits and install malware on your visitors’ computers.

Getting compromised by your website will naturally make your users distrust and avoid it in the future, effectively damaging your online reputation.

Both Firefox and Chrome have started to block mixed content by default, allowing users to manually opt to load content over HTTP. Nonetheless, since mixed content is a security risk, both browsers do show a mixed content warning to users, which can also negatively affect your website’s reputation.

Performance issues

Besides security, the ever-increasing adoption of HTTP/2 by the industry has brought numerous performance and security upgrades to the Web.

Although the increase in performance seems counter-intuitive since HTTP/2 only works over encrypted HTTPS connections, the protocol allows browsers to use a single encrypted connection with an HTTPS web server for all their communications.

Reusing the same connection removes the overhead imposed by repeatedly establishing new ones (i.e. that handshake again). This means that jumping from encrypted HTTPS connections to unencrypted HTTP on a site with mixed content is in fact slower and more resource-demanding than visiting a completely protected site using a single HTTPS connection.

HTTP/2 also implements the 0-RTT session resumption mode, allowing browsers to resume a paused session with an HTTPS website they have visited before, using only a single request (instead of a complete handshake). This makes HTTP/2 resumption at least as fast as an unencrypted HTTP connection, while still providing all the benefits of HTTPS. Serving mixed content means that your website cannot take full advantage of this or any of the other great features of HTTP/2.

In both of these cases, HTTP/2 improves the speed of  your visitor’s connection to your site – and speed matters. Studies have shown over the years that responsiveness and page load speed are critical user interface design requirements. The slower a website’s response time is, the less likely it is for users to stay engaged, and user engagement directly affects your website’s user experience (and consequently your conversion rates).

Mixed content can also affect performance in the level of the underlying web technologies used in your website. Browsers now limit javascript features such as Service workers and push notifications to secure contexts only, because they could otherwise be abused by hackers for malicious purposes. This again means that your website cannot take advantage of any of these technologies when serving mixed content.

SEO issues

Search engine optimization (SEO) is the bread and butter of on-line business marketers. SEO refers to the practice of improving the ranking of a website in a search engine results page (SERP), which directly affects the volume of the website’s traffic.

Google has confirmed that their search result ranking algorithm gives a small rank boost to websites that are served over HTTPS. Since the boost is real-time and per-URL, serving a website in its entirety over HTTPS will result in a SEO boost for the whole website (instead of only those URLs that are served over HTTPS). Granted, this ranking signal boost is quite lightweight when compared to others such as quality content or user traffic, it still rewards your investment in removing mixed content.

Google has also recently announced that page load speed and general website performance is taken into (heavy) consideration when deciding ranking. This means that HTTP/2’s performance optimizations and removing mixed content can work together to boost your website’s visibility on the web.

Finally, if you wish to take full advantage of SSL in your website’s SEO you might consider SSL.com’s EV certificates, which offer the highest assurances to your visitors via security indicators (like that green bar in the browser) to keep them secure and engaged with your content – and longer visits equal higher rankings.

Browser Mixed-Content Warnings

Visitors to sites protected by SSL expect (and deserve) seamless protection. When a site doesn’t fully protect all content, a browser will display a “mixed-content” warning. When your customers see this warning, they can react one of two ways. If they don’t take security seriously, they will ignore it, click through and presume everything will be okay (very bad). If they do take security seriously, they will pay heed to it, back out of your site and assume that you don’t take security seriously (even worse).

Furthermore, all modern browsers will block the more malicious types of mixed content – and in doing so may break your site.

The best solution, of course, is to make sure that these warnings and/or blocks won’t occur in the first place by correctly configuring your site to serve only secure content.

Why Am I Seeing This Warning?

A mixed-content warning means that both secured and unsecured elements are being served up on a page that should be completely encrypted. Any page using an HTTPS address must have all content coming from a secured source. Any page that links to an HTTP resource is considered insecure and is flagged by your browser as a security risk.

Mixed-content warnings fall into two categories: mixed passive content and mixed active content.

Mixed Passive Content

Passive content refers to items which can be replaced or altered but can’t change other parts of the page – for instance, a graphic or photograph. Probably the most common cause of all mixed content warning is when a (theoretically) secure site is configured to pull images from an unsecured source.

Mixed Active Content

Active content can alter the web page itself. A man-in-the-middle attack could allow a request for HTTP content on any HTTPS page to be intercepted and/or rewritten. This makes malicious active content very dangerous – user credentials and sensitive data can be stolen, or malware installed on the user’s system. For instance, a bit of JavaScript on an account-creation page designed to help users generate a random password could be replaced by code providing a random-seeming but pre-generated one instead, or to deliver an otherwise secure password secretly to a third party.

Active mixed content can be exploited to compromise sensitive private data, but even public-facing web pages which seem innocuous can still redirect visitors to dangerous sites, deliver unwanted content or steal cookies for exploitation.

All modern browsers will block active mixed content by default (which may break an incorrectly-configured site)

Why and How to Fix Mixed-Content Warnings

Securing your website lets your visitors trust you, which is vitally important. However, eliminating all insecure content from your site has an even greater bonus of eliminating false positive warnings – if your correctly-configured site is compromised, any insecure element an attacker inserts will trigger the mixed-content warning, giving you an extra tripwire to detect and address these issues.

Again,the best way to avoid mixed content issues is to serve all content via HTTPS instead of HTTP.

For your own domain, serve all content as HTTPS and fix your links. Often, the HTTPS version of the content already exists and this just requires adding an “s” to links – http:// to https://.

For other domains, use the site’s HTTPS version if available. If HTTPS is not available, you can try contacting the domain and asking them if they can make the content available via HTTPS.

Alternatively, using “relative URLs” lets the browser automatically choose HTTP or HTTPS, depending on which protocol the user is using. For example, instead of linking to an image using a link with the “absolute path” of:

<img src=”http://somedomain.com/image.png”>

The site can use a relative path:

<img src="//somedomain.com/image.png”>

This allows the browser to automatically add either http: or https: to the start of the URL as needed. (Note that the site linked to will need to offer the resource over both HTTP and HTTPS for relative URLs to work.)

The first request problem

We hope that up to this point, this article has laid a few good arguments against mixed content, although even if you decide to migrate your website entirely over to HTTPS there are still some improvements you can make.

When users type the URL of your website in a browser, they typically never fully type the protocol name (i.e. https://). Naturally, the browser does not know which protocol your website is served under and defaults to HTTP.

If your website is configured correctly, it will redirect (via HTTP 301/302 responses) the browser to its HTTPS instance; though this means that browsers must perform two requests instead of a single HTTPS request when they first visit your website.

This can be problematic because users can perceive the lag, getting a bad first impression of the site. As such, they will be less likely to stick around which can ultimately lead to decreased visitor traffic.

Moreover, hackers can intercept that first HTTP request to read or modify it before reaching the server. A common occurrence for this type of cases is to perform a network attack called SSL stripping which allows the attacker to replace an HTTPS connection with an unprotected HTTP one.

HTTP Strict Transport Security to the rescue

HTTP Strict Transport Security or HSTS is an attempt to solve this problem. Implemented by the Internet Engineering Task Force (IETF) in RFC 6797, HSTS is an HTTPS header that web servers can include in their responses. This header instructs compliant browsers to always use HTTPS when visiting a website. HSTS applies to all requests including images, CSS stylesheets and any other web resource.

As you may imagine, the browser must first see the HSTS header in order to honor it, which means that HSTS relies on the attackers not being able to intercept that first HTTP request. As a result, HSTS by itself is not a complete solution but rather a simple workaround to SSL stripping.

HSTS preloading

Fortunately, the Chromium project has come up with a solution they named HSTS preloading, which consists of maintaining a public list of websites that have requested HSTS preloading functionality. When visiting a website, Chromium browsers will consult with the list and if the site is found there, they will proceed to communicate with it over HTTPS (including that first request) regardless of previous history or user input.

As a consequence, preloading can improve both your website’s performance and security by removing the initial HTTP request. In addition, it can indirectly enhance your site’s SERP ranking and user experience.

All major browsers (Google’s Chrome, Microsoft’s IE/Edge, Apple’s Safari, Mozilla’s Firefox and Opera) also consult with Chromium’s HSTS preload list, which means that joining this list will provide the preload benefits to your visitors whichever browser they are using.

However, we would be remiss if we did not mention that there are concerns about the scalabilty of the HSTS preload list solution  – It cannot include all websites in the Internet due to practical size and computational complexity limitations, and consequently entry may become increasingly more difficult as time passes and HSTS preloading becomes more broadly adopted.

How can I join?

If you are interested in joining the HSTS preload list, please keep in mind that your website must follow certain rules. The Chromium project has published the list of submission requirements for websites looking to join in their project’s website. The requirements are included verbatim in the following list, however you can find more details in HSTS RFC 6797.

To be accepted in the HSTS preload list, your website must:

1. Serve a valid certificate.
2. Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.
3. Serve all subdomains over HTTPS. In particular, you must support HTTPS for the www subdomain if a DNS record for that subdomain exists.
4. Serve an RFC 6797-compliant HSTS header on the base domain for HTTPS requests:
   • The max-age must be at least 31536000 seconds (1 year).
   • The includeSubDomains directive must be specified.
   • The preload directive must be specified.
5. If you are serving an additional redirect from your HTTPS site, that redirect must also have a compliant HSTS header (as must the page it redirects to).

Here is an example of a valid HSTS header.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

You can test your website for eligibility by visiting the preload list website and entering your domain in the input box. The web application there will point out what issues (if any) you need to fix.

Unfortunately, the complexity of modern websites does not allow one to come up with a one-size-fits-all server configuration for HSTS preloading to include in this article. There can be run-time issues with third-party or other custom components that must be individually resolved.

Although the Chromium project has included some deployment recommendations in the preload website, we are always happy to help our customers improve their communications security. Just drop us an e-mail at support@stg.ssl.com and an expert will be happy to discuss the best path forward for your security needs.

Conclusion

HTTPS is becoming the default Web communications protocol, and fully committing to it can only have positive effects for site owners and visitors. We recommend removing any mixed content from your websites to avoid unnecessary issues (and unhappy users).

As always, thanks for choosing SSL.com, where we believe a safer Internet is a better Internet.