Are you also wondering if moving your website from the HTTP address you’ve been using makes sense to a more secure HTTPS version? And would you like to know what you can and can’t expect in advance?

Switching to HTTPS is not easy, so you need to weigh up the pros and cons at the outset. This article summarizes all the possible pitfalls you may encounter when moving to HTTPS and lists the main reasons why you shouldn’t (not) go ahead with implementing HTTPS on your website.

But first, let’s review what HTTPS is.

What is HTTPS?

Image 1 – Sample link bar with an HTTPS protocol

HTTPS (Hypertext Transfer Protocol Secure), like HTTP (Hypertext Transfer Protocol), is an Internet communication protocol that is used to transfer data on the Internet.

You have probably already encountered HTTPS. You just might not know about it. The easiest way to spot an HTTPS-secured site is to look in the address bar and see if you can see a picture of a green padlock.

Figure 1 – sample HTTPS address bar

How do HTTP and HTTPS differ from each other?

HTTPS differs only in that the data that is transmitted between the server (the web page you want to view) and the client (your web browser) is encrypted. And it’s therefore more difficult to eavesdrop, monitor or modify.

HTTPS also authenticates the counterparty (who is actually sending the data). So users know who they are communicating with and that no one is trying to trick them.

However, even using HTTPS does not mean that communications cannot be intercepted or modified. Using MITM can of course do this, it’s just a bit more complicated.

Note: MiTM (man-in-the-middle) is a method that involves an intermediary (usually an attacker) between two communicating users who “could listen to communication”/eavesdrop all traffic and send both entities their own encryption keys, which allows them to access and modify the content of encrypted messages. Thus, neither of the users may be aware of the existence of this intermediary.

How does HTTPS work?

The security system for HTTPS is provided by the SSL protocol, which is based on trusted certificate authorities. These certificate authorities are companies from which you then buy a trusted SSL certificate. I’ll coverthe problems associated with the whole process of procuring a certificate from different CAs later.

Anyone who uses SSL must have a list of trusted certificates “installed” in their system, i.e., a “list of counterparties” that they trust and are willing to communicate with (i.e., trust).

By default, every ordinary user’s operating system already contains some trusted root CAs (such as Verisign or Comodo). The web servers you communicate with have certificates signed by these trusted CAs.

That’s about it in a nutshell.

Certificate authorities

Certificates authorities – HTTPS – how does it work?

There are trusted companies that you can get a certificate to. The cost of this certificate is based on where the company you are buying the certificate from is “up the food chain”.

In fact, certification companies can also grant credentials to other companies, making them other certification authorities, who can sell these certificates (usually at a lower price) as well, and they, in turn, can resell these credentials, etc.

Figure 2 – the CA diagram – is just to illustrate how CAs work. In practice, most CAs are level 1-2.

Thus, the price of a certificate will vary depending on which entity you are buying the certificate from. In general, the longer the CA you buy a certificate from has been in existence, the more expensive the certificate you buy tends to be.

Note: Your certificate may be trusted even if it is not directly signed by a trusted CA. This can be done by using an intermediary – another CA. So, for example, if there is a generally recognized CA A that signs a trusted root certificate for CA B, then you can use the certificate from CA B as trusted as well.

This “trust-path” can be chained essentially indefinitely, so that you can easily get 3 more certificates in addition to your certificate that make up the trust-path for the certificate you just bought.

This can cause problems if the intermediate certificates that are needed to verify your certificate are not listed in the correct order, or if one of the certificates in this chaining is invalidated.

Figure 3 – Certificate Authority Schema

For this reason, it’s a good idea to try to keep the trust-path as short as possible – unfortunately, this usually has a major impact on the cost of the certificate.

You can check the correct deployment of an SSL certificate here: https://www.ssllabs.com/ssltest/analyze.html.

What can happen if you don’t use HTTPS?

Imagine you are logging in to an insecure website, and someone catches your password on the way and has your login details for that account. You can probably imagine what a big scare this situation can be for banks and their users who, for example, log in to e-banking.

However, this is not the only risky situation that could arise. Imagine sending some data to your users and an attacker changing it along the way. For example, after the customer fills out an order, they are given a different payment gateway address and the unsuspecting customer sends money to someone else entirely. And there are more similar risks with insecure transfers.

Any kind of custom content (viruses, banners, etc.) can be uploaded to an insecure website. Your competitors could, purely hypothetically, post inappropriate content on your website or harm you in any other way they choose. And you can do the same with your competitors if they don’t have their site secured yet :-).

In what situations should HTTPS be used?

Basically, for any site where data theft or alteration could cause irreparable damage, i.e., basically for all sites :-). It’s just that not everyone is as concerned with protecting their users’ data as, for example:

• E-shops, where online orders can be filled and credit cards can be used to pay, and it is necessary to prevent misuse or theft of important personal or payment data.
• Banks and financial institutions that handle customer payment and personal data.
• In the public administration, in the authorities, as these institutions very often work with sensitive data (date of birth, address, birth number, etc.) and, like all other entities, must protect your data properly.
• For other websites that process customer data online in any way (emails, addresses, phone numbers, payment details).

It is for these segments that data protection is the number one priority.

You probably also wouldn’t trust your bank with your money next time you lose money due to their poorly secured internet banking. Or if the bank’s application turned out to be leaky, so someone could install a virus on your computer and you had to arrange for a fix at your own expense…

How did it all start – the HTTPS hysteria?

HTTPS started to be a hot topic about two years ago when Google issued a statement warning that sites using HTTPS (= SSL certificates) would be slightly favored from an SEO perspective and thus likely to appear higher in search results.

Just for the record, Google even supported this change back in 2012, two years before the term HTTPS started to be used in all senses, mainly for SEO reasons.

To set the record straight – while Google has announced that it will give preference to sites on HTTPS, Google itself claims that HTTPS has very little weight and affects about a percentage of queries. Therefore, switching to HTTPS “just” because of the search engine makes essentially no sense.

Because there are hundreds of similar signals that the search engine evaluates. And if the use of HTTPS had even a one percent contribution to the final Google rankings, it’s probably not worth it anyway. If only because there is a huge amount of work involved. After all, the martyrdom that awaits you is discussed in more detail below.

You don’t even have to worry about your website dropping dozens of positions. Even this opinion can be easily denied. Nor are you at risk of being penalized because your site is still running on insecure HTTP. It’s just something you can do, and you get a little extra benefit. But if you don’t do it, nothing terrible will happen. Actually, almost nothing, as the results show most users who have been tempted to switch to HTTPS “for SEO”.

You should switch to HTTPS for the users’ sake, to protect their privacy. Because probably nothing looks worse than when a security issue breaks and then users’ data runs rampant across the internet and everyone knows it’s YOU! It can be even worse if you are a company that provides hosting, produces websites or runs an online wallet, for example…

So now – what’s really in store for you if you decide to switch to HTTPS, and what are the advantages and disadvantages?

Disadvantages:

Cost of the certificate – when you switch to HTTPS, you have to buy an SSL certificate, which you have to renew annually.

However, you can of course get an SSL certificate for several years in advance. So there is no need to manually renew it every year if you don’t want to, the whole process can be automated, it will just cost you some extra time again to figure out how. Either way – you always have to pay for the certificate.

It is not a staggering amount of money unless you need to secure hundreds of websites in this way (and if you do, amounts in the order of thousands are probably not a significant problem for you because you are at least a medium-sized company for which amounts in the order of a few (tens of) thousands will not be liquidating).

I would add here that a lot depends on the certification authority, i.e., the prices you find below may vary (significantly). I’m just giving them as an idea – just to give you an idea of how much it might cost.

Certificate prices vary by type:

• Automated Trusted SSL Certificate from Let’s Encrypt. The cheapest (free) option, but it doesn’t do Wildcard and SAN (see below). The second problem is that they will issue this certificate to anyone who asks for it. Just submit a request, and you have a certificate. So the problem is that the site we are looking at, although secure, has a fraudulent SSL certificate in addition to the fraudulent content. It’s also worth noting that some Czech hosting sites already offer auto-SSL functionality. That is, all hosted sites at a given host have an SSL certificate (Let’s Encrypt), which is either free or for a nominal fee.

• Basic SSL – a certificate can be purchased from about €5.52/$5.63 per year and is usually for one domain.

• SAN/UC (Subject Alternative Name/Unified Communications) – these certificates allow you to protect multiple domains with one SSL certificate.

• The price of these certificates can start at the cheapest ones at €13.11/$13.74 per year, and with this “cheap” certificate, you can secure up to 3 domains at once. Of course, there are also variants that allow you to secure 10 or more domains with one certificate. However, you can expect that such a certificate may cost you around €75.14/$76.83 per year.

• SSL Wildcard certificates (also referred to as star certificates) – are a universal type of SSL certificate that allows you to secure all subdomains under one main domain. A Wildcard certificate contains an asterisk before the main domain name (e.g. *.seznam.cz) and its use saves financial costs of purchasing additional SSL certificates and, last but not least, the time required for their installation and management.

• The price of these certificates starts at €39.47/$40.81 per year. Like SAN/UC, they can also be purchased in a version that allows you to secure multiple wildcard domains with one certificate. SSL wildcard certificates allowing to secure up to 9 main domains including their subdomains cost €717.57/$754.12 per year.

• IDN SSL (Internationalized Domain Names) – are certificates used to secure domains that use characters outside the standard Latin alphabet (a-z). IDN SSL certificates can be used to secure, for example, websites with Russian or Chinese characters in their names. The cheapest version of IDN SSL can be purchased from €7.46/$7.86, IDN SSL certificate for securing up to 100 domains can cost you nearly €1,631.09/$1,674.81 per year.

• The certificates themselves differ not only in price, the number of domains that can be secured with one certificate, but also in the type of authentication:

• DV SSL (Domain Validation) – the most affordable SSL certificate, which uses only basic domain-level authentication, where a verification email is sent. A huge advantage of DV certificates is their fast issuance, which can be done in minutes.

• OV SSL (Organization Validation) – SSL certificates offer a higher level of trust than DV certificates by completely identifying the company for which the SSL certificate is issued. The company validation emphasizes the trustworthiness of the web project operator, the visitor has the possibility to verify the website operator at any time.

• EV SSL (Extended Validation certificates) – this certificate turns the browser address bar green With an EV SSL certificate, the company name is also displayed next to the web address.

As you can see, there are quite a lot of certificates, and I haven’t even mentioned the fact that they differ in encryption and the method of key exchange.

Note: Certificates can also differ in the type of encryption. The most common and most used is RSA.

RSA encryption ( named after the initials of authors Rivest, Shamir, Adleman) – this is essentially the most common form of security that is still used today, with RSA authentication considered secure if the key length is long enough.

It is certainly worth noting that this may not be true in the future. Due to the boom in quantum computing , the US National Institute of Standards and Technology (NIST) is looking into quantum-resistant ciphers. In their report, we can read that RSA, DSA, and elliptic ECDSA and ECDH are not secure if large quantum computers become available.

ECC (Elliptic Curve Cryptography) encryption – is roughly 10,000 times stronger than the most widely used RSA 2048-bit variant. In addition, this significantly shorter 256-bit ECC key requires much less server computing power (CPU and memory) than 2048-bit RSA. But this type of encryption is not used much.

Time is probably the biggest obstacle that will discourage you from switching to HTTPS. You also have to start factoring in the fact that switching to HTTPS will take some time not only to retrieve the information (what certificates exist, which one to choose, and where to buy it) but also to add in the time spent with the implementation itself (in short, you need to know what to put where and how to check it or ensure that HTTPS runs smoothly). Add to that the time spent bug fixing, which you can’t avoid anyway. After all, you can get an idea of what to expect when switching to HTTPS from the following lines.

Complete redirection – you will have to completely redirect the entire site to new URLs that will now use HTTPS instead of HTTP. Which, for larger sites, can be a job for days, if not weeks. For corporate sites, then expect months of hard work and dozens of sleepless nights.

And why is redirection needed in the first place? A website running on HTTPS is a separate website from one that has been running on HTTP. So, from a search engine’s perspective, you actually have two identical websites.

If you want to prevent your website from being duplicated (which is not a desirable state from an SEO perspective), you will need to redirect the old HTTP website to its new HTTPS version.

So you’ll have to redirect one URL at a time using the 301 (Moved Permanently) status code, which means that this is a permanent (and not just temporary) state. Now imagine that you have to solve this whole process for a website that is used by thousands of people every day, for example, and so everything has to go smoothly, ideally so that the end user doesn’t know anything…

More redirection worries

• Next, you need to verify that the redirection works on all subdomains of the site.

• Next, you need to reconfigure all export URLs (e.g. feeds for heureka.cz or goods.cz, where you need to change the feed URL to https).

• The same will be done for images, JavaScript, CSS, multimedia, PDF files, etc.

• You will need to modify all URLs on the site to point to HTTPS sites (use either an absolute URL with HTTPS, a relative URL, or a protocol relative URL “://”)
• You’ll also need to modify the canonical URLs to avoid looping (in short, the user could be redirected to another URL and back again, and so on and so forth).

• You should modify hardcoded URLs (hardcoded links with http:// in articles, JavaScript, CSS files, etc.).
• You should edit the hreflang URL if you use it.
• You should edit the URL in the RSS feed if you are using an RSS feed reader.
• You should edit the URL in Facebook, Twitter, and other interactive buttons, and the same applies to OG:URL meta tags.
• You should create a new robots.txt.

• You should change the location of sitemap.xml files to https:// and edit the sitemap link in robots.txt.
• You should change the URL in the sitemap.xml files to https://.
• For large sites you have to, for smaller sites (up to a few dozen pages) you should keep the original redirect chain. If you already have some redirects on the page, don’t edit the current redirect, but add new rules for redirects from HTTP to HTTPS. This is very important for the Seznam robot. To the existing redirect HTTP://s.cz/stara-url -> 301 -> HTTP://s.cz/nova-url just add (before or after) another 301 redirect 301 -> HTTPS://s.cz/nova-url. Do not shorten the redirect chaining.
• You must redirect URLs with _escaped_fragment_= to their 1:1 alternatives (i.e. from http://www.s.cz/?_escaped_fragment_= -> 301 -> https://www.s.cz/?_escaped_fragment_=),
• You should ensure that HTTPS works on subdomains and external sources from which you will link files – CSS, JS, images, CDNs, etc.
• You should test the previous points before deploying (for example, using Screaming Frog, or Xenu’s Link Sleuth)

Changes in Google Analytics, Adwords, Sklik, and other campaigns – the next necessary step is to reconfigure URLs in Google Analytics to switch to HTTPS. If you don’t do this, Google Analytics will not measure you.

You should add the HTTPS version of the site to Google Webmaster Tools (for HTTPS site statistics).

• You should change the URL of the site wherever you use it, e.g.: PPC campaigns (Sklik, Adwords, Facebook, etc.), banner and other campaigns, affiliate links, opensearch.xml.

• Then you should probably also change the URL in email signatures, autoresponders, etc. However, this is no longer a must-have but rather a nice to-have.

Still, feel like switching to HTTPS?

And to make matters worse, until recently, Seznam, in particular, had a problem with indexing sites converted in this way, which resulted in a noticeable drop in traffic (this situation lasted almost a year, and Seznam managed to resolve it in April (allegedly).

Although Seznam claims that everything is now fine, it is still important to keep in mind that nobody guarantees a smooth transition to HTTPS at Seznam: “Unfortunately, short-term drops can still occur in individual cases (the larger the site, the more prone to the problem it is).”

But then again, that’s true for any massive address changes. In short, you never know how a site will eventually go down.

Other responsibilities

With HTTPS, you, as the operator, will also need to be on the lookout for certificate expiration and generate and deploy a new certificate in a timely manner. Otherwise, visitors will be greeted with an unpleasant red alert informing them that the site does not have a valid certificate. Of course, SSL certificate renewal can also be automated, but again – it will cost you extra time to figure out how to do it. And time is money…

Add to that the need for testing during the migration to HTTPS and the errors that are likely to occur and that you will need to address during the migration to HTTPS.

You’re bound to forget or misconfigure something. And last but not least, take into account that it may take a while for search engines to notice that some change related to HTTPS conversion has taken place, which may result in a temporary (but also permanent drop) in positions (especially for Seznam) and resulting lower traffic.

Advantages:

• Security – basically, this should be the main reason to switch to HTTPS. The data being sent will not be as easy to intercept and you will significantly eliminate the risk of a potential data leakage problem.

• Speed – While HTTPS is considerably more complicated to use than HTTP, using the SPDY protocol can noticeably increase the speed of loading a site by bundling requests for individual files. If a site is loading a large number of objects (typically images that cannot be merged into one) with HTTP, the overhead of creating the request itself takes a significant amount of time. SPDY can group file requests together and thus achieve a noticeable increase in site loading speed.
• You’ll save yourself time in the future – you won’t have to make this change later. Because sooner or later, HTTPS will probably be the standard. So you can get a bit of a head start and make this change now. As security expert Michal Špaček writes: “The next version of HTTP only counts on encrypted traffic, in simple terms HTTP 2.0 will be just HTTPS. Google may one day stop handicapping HTTPS sites, but that will be a signal that such sites are the majority. Maybe this favoritism is also a way to speed things up.”
• You get that one extra SEO point now, while Google still officially favors sites that have switched to HTTPS :-).
• You’re managing sensitive user data and want to increase your site’s credibility and level of data security.
• You are launching a new website/eshop (and then you are basically creating everything from scratch and don’t need to do any migration from HTTP to HTTPS)

So when does it make sense for you to tackle HTTPS?

• You don’t want to deal with the migration to HTTPS later when you have to (HTTPS will be the standard for most sites).

• Just for SEO’s sake, it doesn’t make sense to migrate, as confirmed by Dusan Janovsky from Seznam: “There are many questions about whether it’s a good idea to move sites to https: protocol. They say that Google wants it. I say that it is stupid to change URLs for nothing.”

Sources:

• www.ssls.cz
• vyhledava.cz/google-how-first-will-index-https/
• www.michalspacek.cz/prednasky/https-ctvrtkon
• jakdelatseo.cz/checklist-for-transitioning-from-http-to-https/#zacykleni-canonical-tag
• www.lukaspitra.cz/http-ssl-nove-seo-faktor-google/
• jecas.cz/https