Moving your site to HTTPS isn't just a good idea, it is vital to your success, but doing so presents some challenges that you may not be aware of. Here we outline some of the challenges you'll face and issues you need to pay attention to when you add HTTPS to your site.
HTTPS is a protocol for secure communication over a computer network. In the early days of the web, the only reason a website would choose to use HTTPS was either (1) to secure pages with direct user interactions with a strong need of security, such as payment forms and password login pages, or (2) when the information being presented was of a private nature, such as bank account rosters. Unfortunately, HTTPS was also expensive, difficult to implement, and sometimes resulted in poor performance issues. Thus, most websites did not use HTTPS.
As we mentioned back in January, Google and other organizations have been pushing hard for a more secure web, in some cases penalizing websites that do not utilize HTTPS. Today, having HTTPS for your website is vital for your web success. Fortunately, some of the original challenges of implementing it have been eliminated, or at least reduced.
What Has Gotten Better
Cost and Paperwork
At first, webmasters could only purchase SSL certificates from a handful of trusted Certificate Authorities. Coupled with the complicated requirements these Certificate Authorities imposed on issuing certificates, acquiring an SSL certificate resulted in particularly high costs for webmasters. The end result was that only companies that were making money directly from their websites found the idea of purchasing SSL certificates of any particular value. It was hard to justify hundreds of dollars per year, not to mention a mountain of paperwork, for your website if it wasn’t vital to your business (not to mention the other issues that went along with HTTPS).
Over the past couple of decades, the number of Certificate Authorities has increased dramatically. As a result, it is now possible to get an SSL Certificate very cheaply, and and without a great deal of paperwork simply to verify that you are the valid operator of your website. Companies who want extra levels of verification can still do all that paperwork and shell out hundreds of dollars to get an Extended Validation (EV) Certificate (most browsers distinguish these websites with EV Certificates with a “green bar” in the URL), but for most websites that only need to secure the connection between the user and the server, Domain Validation (DV) level certificates is plenty.
There are even a few providers that will let you get SSL Certificates completely free. Cloudflare, the popular Content Delivery Network (CDN) and Web Application Firewall (WAF) provides ALL of their customers, including users of their completely free plan, with a completely free SSL Certificate that is issued automatically. Amazon Web Services (AWS) can also issue you free SSL Certificates but only if you connect them to either their Cloudfront CDN or Elastic Load Balancer services. If you don’t want to pass all your traffic through a third-party provider, LetsEncrypt can provide you free SSL Certificates that you can run on your own server.
Technical Challenges
Even for those companies that did bite the bullet and shell out the dough for an SSL Certificate, moving your website to HTTPS wasn’t just a matter of paying for the certificate; installing that certificate required significant technical knowledge.
For one thing, before the introduction of Server Name Identification (SNI) into the Transport Layer Security (TLS) protocol in 2004 (and more importantly since the point that people started using browsers that supported it), having HTTPS required that your website have a static IP Address. This was because of the way the browser-to-server connection was secured. Only one SSL Certificate could be returned for each IP address on the server because this certificate was transmitted on the initial connection before the browser identified which site it was planning to load.
Almost all current browsers and web servers now support server name indication (SNI), which allows multiple SSL Certificates to be run on the same IP address. With the IPv4 IP space exhausted back in 2015 and the vast majority of networks not yet upgraded to IPv6, it would not even be possible for the vast majority of websites to move to HTTPS without SNI.
Also using a CDN like Cloudflare or Cloudfront can vastly simplify the task of adding SSL to an existing website as you don’t have to make any changes on your server itself.
User Performance
Especially in its early days, HTTPS significantly slowed down the loading of pages because every request to the server required an additional round-trip between the user and the server in order to establish the secure connection before any data would be loaded.
Both the browser and the server are required to encrypt and decrypt any data transferred between them. This put additional processing requirements on both the user’s computer and the server hosting the site. In earlier days this additional processing would slow down the connection on both ends.
The biggest improvements in HTTPS are in the realm of speed. With advancements in technology, the act of encrypting and decrypting content is now much less CPU-intensive and extremely fast. What’s more, if you couple your HTTPS implementation with the new HTTP/2 protocol, HTTPS is not only fast, but it can actually be faster than HTTP (as no browser supports HTTP/2 over HTTP). HTTP/2 allows for enhancements such as multiplexing which allows all of the resources for a page to be transmitted through a single connection simultaneously, reducing a significant portion of the overhead in loading web pages.
What Has Not Gotten Better
There are a number of problems with implementing HTTPS that you need to be aware of before and while you implement HTTPS on your website.
Mixed-Content Problems
Browsers enforce rules on HTTPS that require that if a page is loaded via HTTPS, all content on that page (every image, every JavaScript file, every embedded video, etc.) must also come from HTTPS. If any content on the page was not HTTPS, the user’s browser would issue a warning to the user that the page was not secure. In some browsers this warning was so strong that the page would not load at all until the user explicitly opted to proceed despite the warning.
This is an especially salient issue if you embed content from third parties. Any time you attempt to embed content from a third-party provider, you must make sure that the content is also hosted on HTTPS otherwise browsers will not allow the content to render. We’ve particularly seen this problem when it comes to embedded video. While large video providers such as Youtube and Vimeo run on HTTPS and thus can be embedded on HTTPS sites just fine, there are still a lot of videos out there hosted on only HTTP pages. Many TV channels and news organizations choose to host their own videos on their own sites, and not all of them have made the migration to HTTPS yet. Until they do, you cannot embed any videos from these sites on your own HTTPS site.
Images and JavaScript also need to be loaded from HTTPS endpoints, and any forms on your HTTPS pages must also submit to other HTTPS endpoints.
Certificate Management
Just like it is important to keep your domain renewed whenever it comes up for renewal, SSL Certificates have to be renewed. Unlike the 10-year limit on most domain registrars, certificate authorities don’t let you register SSL Certificates longer than 3 years. If you opt for the free certificates from LetsEncrypt as mentioned above, they expire after only 90 days, meaning you have to constantly renew your SSL Certificates.
If you don’t pay close attention and miss the renewal of your certificate, users attempting to access your site will get frightening warnings that your site has been compromised.
Certificate Revocation
In addition to normal expiration, you also need to keep an eye out for certificate revocation. Certificate Authorities issue revocations, remotely disabling SSL Certificates. While most of these revocations are individualized to a single SSL Certificate, there have been instances in the past where certificates were revoked en masse. One of the most notable instances was in 2014 when the Heartbleed bug (more on that below) resulted in most Certificate Authorities re-issuing their own intermediary certificates, which in turn required everyone else to re-issue their own certificates.
In addition to individual certificates being revoked, you might end up in a situation where your certificate chain has been distrusted. Back in October, Google, Mozilla, and Apple all announced plans to distrust certificates issued by two previously trusted certificate authorities (WoSign and StartCom). The reason for this distrust has to do with these certificate authorities issuing some certificates without following the industry vetting standards to determine trust. At the time they claimed that they would only reject certificates issued after that date while continuing to allow certificates issued before that date, however, with the release of Chrome 57 in March, certificates issued well before October were no longer trusted.
More recently, Google has been “going to war” with large security company Symantec saying that the latter granted thousands of EV SSL Certificates without verifying the identities of the purchasers of the certificate. In response Google is proposing a plan to gradually distrust all existing SSL Certificates issued by Symantec over the coming year, requiring anyone who had purchased such certificates to re-issue their certs.
If you have an SSL Certificate on your site issued from one of these three providers, you need to replace these certificates right away to prevent lost traffic to your site. If you have a certificate from WoSign or StartCom, you have to purchase a new SSL certificate from another provider. Fortunately, if you have a certificate from Symantec, Google is warning that you’ll be able to simply re-issue your Symantec certificate after re-validating your identity without purchasing a new certificate.
It is important that you keep an eye out for changes not only in your own certificate but in the way browsers trust the organization you acquired your SSL Certificate from.
SSL Vulnerabilities
When you run any server that is accessible on the internet you have to constantly keep it updated and patched for new security vulnerabilities. Of all the security vulnerabilities announced over the last few years, the majority of the worst of them were related to SSL.
As I mentioned above, the Heartbleed bug in 2014 was a particularly nasty bug because it compromised the private keys of SSL Certificates (thus allowing third parties to potentially decrypt the data transmitted in an HTTPS session).
The DROWN Attack in 2016 allowed attackers to break all encryption on a server and access all data transferred between the user and server.
The LuckyNegative20 attack effects the CBC Cipher suites, and allowed data that was in memory to be accessed remotely.
All of these (and a large number of other vulnerabilities over time) have resulted in the need to patch your server in order to keep your HTTPS pages secure, and in some cases (like Heartbleed) have required you to re-issue your SSL Certificates even if they weren’t yet due to be renewed. When you run an HTTPS site, you need to stay on top of all the latest security vulnerabilities and be constantly patching your servers to make sure your website remains secure.
Duplicate Content
When you add HTTPS to your site, you need to make sure that you handle the fact that your HTTP and HTTPS sites are seen as separate sites by search engines and unless you properly add canonicals and redirects, you can damage your own SEO by creating an entire site of duplicate content. The best solution is to 301 redirect your HTTP page requests to the corresponding HTTPS page so that there is only one version of your site (the HTTPS version).
HTTPS Today
Google and Mozilla recently announced that over 50% of desktop user traffic is now loaded under HTTPS as of October, and following their stats, as of this month, it is now 50% across ALL browsers they track as of this month (including mobile).
That’s tremendous progress in securing the entire web, but keep in mind the key word here. The chart is labeled “Percentage of pages loaded over HTTPS” not “Percentage of sites loaded over HTTPS.” When you consider that the sites with the most traffic are 100% HTTPS (Google, Youtube, Netflix, Facebook) are all loaded on HTTPS, and you see other statistics indicating that as of 2015 37% of all internet traffic went to Netflix and another 18% went to Youtube, the stat that 50% of all internet traffic is HTTPS seems a bit less impressive.
HTTPS advocate Troy Hunt said in January that he believes we’ve reached the critical mass tipping point for HTTPS adoption, and he is probably right, but in the same article where he lauded the 50% of all requests statistic, he also pointed out that only 18.4% of the top 1 million websites on Alexa redirect HTTP to HTTPS.
You need to upgrade your site to HTTPS now
Google announced back in 2014 that HTTPS is now a ranking signal. As more and more of the web becomes HTTPS, this ranking signal could become more important.
In January of this year, both Chrome and Firefox started warning users that they are on a non-HTTPS page that contains either credit card or password form fields. Both browsers have announced that future versions of their browsers will put up warnings on ALL non-HTTPS page loads. It is vital that your website be moved to HTTPS before that happens.
Justia makes sure to keep on top of the latest moves in the web such as Responsive Design, AMP, and of course HTTPS Everywhere. We specialize in law firm website SEO and design, and we understand the nuances of SEO that uniquely affect law firm websites. If you need to update your law firm website to the latest web technologies, contact us; we’ll be glad to talk to you.