The fundamental process for deploying HTTPS is straightforward, and there are a wealth of resources online and in print to help you get started. Here's a list of recommended resources to help you understand HTTPS and how to go about deploying it:
That said, deploying HTTPS is often anything but simple in practice. This is especially true for news organizations, because their websites are often large, may have numerous legacy components, and often feature embedded content and advertising from a variety of domains that may or may not be under their control.
As part of developing Secure the News, we interviewed people from several different news organizations that have recently deployed HTTPS. We wanted to know what was easy, what was hard, and what they wish they knew before they started. What follows is a list of potential issues, "gotchas", and recommendations based on these interviews.
Once you've deployed HTTPS, you will have to deal with the fact that both your existing content, as well as the rest of the web, are full of URLs pointing to your old, insecure website (e.g. "http://yoursite.com"). Fortunately, there are number of things you can do to ensure users are connecting to your new, secure site—no matter where they are coming from.
Many large websites are not directly accessible by their end users; instead, their content is delivered through a Content Delivery Network (CDN), such as Akamai, Cloudflare, Amazon Cloudfront, etc. Using a CDN is usually cost-effective for large websites, and allows them to focus on improving the core experience of their web application while leaving the details of scaling content delivery to the CDN. CDNs also typically operate servers around the world, which helps optimize web content delivery for a global audience.
The Washington Post reported that one of their initial hurdles was with their old CDN, which wanted to charge them a significant amount of money to migrate their CDN-delivered content from HTTP to HTTPS, in addition to the increased ongoing cost for using HTTPS on their network. Other news organizations have described similar issues with their CDNs.
We believe these hurdles are caused by CDNs that have an outdated way of thinking about the web, where HTTPS was a luxury commodity that was only required by sites like banks or payment processors. Fortunately, the situation is changing in the CDN market and there are now many CDNs that offer reasonably priced or even free HTTPS content delivery. Talk to your CDN about migrating to HTTPS, and if their terms are prohibitive, consider some of these alternatives:
On the modern web, web pages typically load many subresources—images, audio, video, scripts, etc. Subresources may be loaded from the same or a different origin as that of the site itself; for example, yoursite.com might load an image from yoursite.com/images (same origin), and embed a YouTube video from youtube.com (different origin).
For a secure website to be truly secure, both the site itself as well as all of its subresources must be loaded from a secure (HTTPS) origin. Insecure content that is loaded by a secure page is called mixed content. Due to the risks involved, web browsers will either block mixed content entirely, or they will allow it to load but will downgrade the HTTPS lock icon to indicate the potential security risk—the specific response depends on the type of mixed content and the policy of the browser.
Mixed content is often a problem for news organization's websites because they have a preponderance of:
For both embedded media and advertising, the best solution is to fix the problem at the root: work with your content and advertising providers to ensure that their content is available over HTTPS, and use the HTTPS URLs on your site. This is the case today for most major content providers (such as Facebook, Twitter, Instagram, and YouTube) and for many of the big ad networks.
Note that some content providers may provide insecure HTTP embed links by default, but do in fact support HTTPS. We recommend consulting the site's documentation or support if you are unsure. EFF's HTTPS Everywhere Atlas can also be a useful resource.
If you find you have content or advertising partners that do not support HTTPS at all, the best thing to do is contact them and ask them to support it, or considering switching to an alternative provider.
Everyone that we interviewed stressed the importance of working with internal advertising and content teams from the beginning of the transition process to develop protocols for vetting content and assist in communicating with content and advertising partners.
Unfortunately for many sites, their advertising's "creative" content is controlled by third parties, and can change over the lifetime of a particular campaign or ad buy. In practice, this means that an ad that was verified HTTPS-compliant and approved may suddenly change without warning and stop working due to mixed content blocking.
While this cannot always be prevented, it can be detected, by sending a Content-Security-Policy-Report-Only header and setting up a CSP reporting endpoint. CSP Report-Only enlists your user's browsers to look for violations of a given security policy, and to send detailed reports to the provided endpoint when a policy violation occurs. For example, sending the response header "Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint" will cause your user's browsers to send a violation report to "/endpoint" every time your site attempts to load an insecure resource.
Content-Security-Policy-Report-Only is useful not only for catching misbehaving embedded content, but also for identifying the long tail of insecure sub-resources and links in a large site.
Note that when CSP reporting is deployed at scale, you may find yourself receiving a lot of report traffic. It is also usually desirable to have a dashboard to help you parse incoming reports in real time. There are a number of open source projects that implement CSP reporting endpoints, and we've also heard good things about third party services like report-uri.io and Sentry.
SEO is a tricky topic because the inner workings of large search engines are closely guarded secrets. Google has said that they are now using HTTPS as a positive signal in their site ranking algorithm, although everyone we spoke to said that any boost to their rankings after transitioning to HTTPS was either small or unnoticeable.
Generally, most people that we spoke to said they did not encounter any serious issues with SEO during their transition to HTTPS. One organization, Wired, did report seeing a worrying reduction in SEO rankings after switching some sections of their site over to HTTPS as part of a gradual transition. Their rankings have since recovered. While they were never able to pinpoint the cause of the temporary change, they did write about their experience in detail here.
To avoid similar issues, we recommend monitoring your own analytics and using Google's webmaster tools as you transition your site to HTTPS. We also recommend reading:
Large and long-running websites often have lots of subdomains devoted to different specialized purposes. Some of these subdomains may run on separate infrastructure from the main site, which means additional work may be required to transition them to using HTTPS.Subdomains are primarily an issue if you are considering deploying HSTS to harden your HTTPS deployment. HSTS has an optional flag, includeSubDomains, which allows you to specify whether or not HTTPS should also be enforced on all of the subdomains of the domain that is serving the HSTS header. Setting includeSubDomains makes your deployment more secure, but it should be deployed carefully—if any of your subdomains do not actually support HTTPS, setting HSTS with includeSubDomains will make those subdomains inaccessible.
Finally, many of the large news organizations that have recently deployed HTTPS have been admirably transparent about their process and the challenges they faced along the way. Their writeups are worth reading for anybody considering deploying HTTPS at a similar organization: