Saturday, July 27, 2024
HomeBusinessDo you need to migrate from HTTP to HTTPS?

Do you need to migrate from HTTP to HTTPS?

Full SSL Handshake

Since August 6, 2014, when Google explicitly stated that the HTTPS protocol had become a ranking factor , every day new sites migrate from HTTP to HTTPS to increase the security of their site. But is it really necessary?

Who needs HTTPS and who doesn’t? What should you ask yourself before migrating? What are the best practices to follow? Today I will try to answer these questions.

At the end of the article you will find important considerations by Maurizio Ceravolo on the HTTP vs HTTPS topic (PS: thanks Maurizio!).

When HTTPS is better than HTTP

Not all sites need to encrypt client-server connections, however there are some cases where the HTTPS protocol adds absolutely necessary security factors.

Does your site handle sensitive information? Is it possible to authenticate? Is it possible to make payments through the portal? Is the transmitted data critical? If factors such as privacy, authentication security, data integrity and encryption are elements that you cannot do without, then the choice to migrate to HTTPS is mandatory.

  • Privacy:HTTPS protects browsing privacy . If you browse HTTP, a stranger can see the sites you are browsing and understand your interests and more. If you browse HTTPS, your connection is encrypted and no one can spy on your online activities.
  • Authentication:HTTPS certifies the parties , ensures that you are connected with the right person / company / server and not with someone who is trying to intrude on the communication.
  • Data integrity:HTTPS certifies the data you send / receive. It is not possible for third parties to interfere in the communication and modify the data transmitted in HTTPS. HTTPS offers security during online transactions and the sending of sensitive information.
  • Encryption:HTTPS masks transmitted data making it unreadable to outsiders. Browsing HTTPS nobody can intercept the data.

The HTTPS protocol affects everyone

Several people are involved with the company site: the visitors, the system administrator and the webmaster / developer, each with different interests and doubts:

  • The visitor:why use an unsafe site? How can I protect my privacy? How can I protect my data?
  • The web server administrator:how do you configure the TSL on the web server? How can I improve performance?
  • Site developer and owners:How can I make my HTTPS content friendly? How can I migrate my content from HTTP to HTTPS?

Privacy

  • HTTP:a hacker listening passively on wifi can see the sites I browse.
  • HTTPS:a hacker listening passively on the wifi cannot see the sites I browse because the transmitted data is ent-to-end encrypted , therefore unreadable without the decryption key.

Data integrity and authentication

  • HTTP:An active hacker can modify a site, for example by diverting its internal links to trap pages . You think you have clicked on the official link that leads to your bank instead you end up on a cloned site.
  • HTTPS:an active hacker cannot create a puppet site of an HTTPS certified portal because it does not have the certificate of authenticity.

Through the TSL tunnel between user and website:

  • An active and passive hacker cannot listen
  • An active and passive hacker cannotmodify the transmitted data
  • An active hacker cannotimpersonate the recipient

PRE migration assessments

Before migrating to the HTTPS protocol it is important to ask yourself a few questions in order to plan and implement all the necessary steps in the best possible way.

TLS and speed

  • Are certificates expensive?
  • Doesn’t the HTTPS protocol slow down the site?
  • What are the best practicesin server configuration?

HTTPS and SEO Friendly

  • How can I migrate existing content?
  • How can I make the site SEO friendly?
  • What are the mistakes to avoid?

TLS implementation

Tips for implementing TLS. The System Administrator Checklist:

  • Purchase a 2048-bit TLS certificate
  • Configure TLS on your server
  • Check your server’s TLS configuration
  • Monitor performance: resumption rates, etc …
  • Optimize the server configuration: cache size, etc …
  • Analyze SPDY & HTTP 2.0

Purchase a 2048-bit TLS certificate

  • Single host: tasktip.com (Free, $ 10 +) *
  • Multi-domain: tasktip.com, cdn.tasktip.com, tasktip.us (Free, $ 30 +) *
  • Wildcard: tasktip.com (Free, $ 100 +)

* Most sites require a single host or multi domain certificate.

Info and costs of certificates:

  • Free certificates for non-commercial activities obtainable from StartSSL
  • Free certificates for open-source projects obtainable from GlobalSign
  • Commercial and multi-domain certificates cost $ 30 and up

Configure TLS on the server

  • Don’t follow different guides. Refer to the Mozilla ” Server Side TLS ” wiki for best configuration best practices for Apache, Nginx , HAProxy, AWS and other popular web servers.
  • Check the configuration with Qualys excellent tool

PRO TIPS:

  1. Enabling and prioritizing the ECDHE cipher suite * increases the load on the CPU. HTTP keepalive and session resumptionallow to reduce the load on the CPU
  2. Modern software-based TLS implementations running on common CPUs are fast enough to handle heavy traffic loads via HTTPS without the need for dedicated encryption hardware.

Improvements in loading pages with SPDY enabled:

Google News Google Sites Google Drive Google Maps
Median 43% 27% 23% 24%
95th percentile 44% 33% 36% 28%

Double-digit increases compared to the normal HTTP connection thanks to the better exploitation of resources.

SPDY is supported by Chrome, Opera, Firefox, IE and Safari.

SPDY also brings several advantages to the web server:

  • SPDY requests use fewer resourceson the web server
  • SPDY requests require less memorybut a little more CPU
  • SPDY requests require fewer worker processesin Apache

Other Advantages:

  • Certificates are inexpensive
  • There are great tools for checking the configuration
  • TLS can be obtained in software without having to invest in expensive hardware
  • TLS resumption, false-start, etc, help reduce latency
  • TLS allows you to implement SPDY and HTTP / 2
  • SPDY and HTTP / 2 improve page loading
  • SPDY and HTTP / 2 use fewer resources

Migrate to HTTPS

All indexing signals must be consistent , this means verifying that the URLs indicated in the links, tags, meta, scripts, etc., are pointing to the same resources (or URLs). Don’t link a CSS sometimes with HTTP and sometimes with HTTPS, the signal sent to Google would be inconsistent.

The Webmaster Checklist

  • Read the guide on proper SEO migration of a website
  • Configure HTTPS on the server
  • Update site content to new resources under HTTPS
  • Update internal links pointing them to HTTPS
  • Check the robots.txt file
  • Check the consistency of the rel = canonical , rel alternate, … tag
  • Set up redirects correctly and add HSTS
  • Check the Google Search Console reports and alerts

Configure and verify the TLS configuration on the server

Most common error messages:

  • Incorrect hostname:Check the configuration
  • Incomplete certificate chain:Authentication too slow
  • Expired certificate:expired certificate, write a reminder!

Correct the URIs

Do not use HTTP in the URL indicated in the resources, just enter // to let the webserver decide where to find the resource from

Redirect HTTP URLs to resources in HTTPS

It uses 301 redirects to guide users and spiders to the HTTPS URL.
user / bots -> HTTP URL -> 301 -> HTTPS URL (page with canonical tag)
Remember: redirections are essential, do not keep two versions of the same page live in HTTP and HTTPS . To learn more about SEO friendly migrations, I recommend this guide .
Always consider:

  • Old internal and external links pointing to HTTP
  • Pages saved in favorites, pages shared on social networks, etc that point to HTTP

Eliminate unnecessary redirection chains

better to aim directly at the final resource, avoiding redirection chains

  • NO redirect chains:
    • http://example.com -> http://www.example.com -> https://www.example.com
  • Yes single redirects:
    • http://example.com -> https://www.example.com
    • http://www.example.com -> https://www.example.com
    • https://example.com -> https://www.example.com

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a security policy mechanism proposed for the web where a web server claims to interact with the browser using only a secure connection (such as HTTPS). The policy is communicated from the server to the user agent through an HTTP response header field called “Strict-Transport-Security”. The policy specifies a period of time during which the user agent would access the server in secure mode only.

Apache

Enable the Headers module on Apache.

a2enmod headers

Add a header to the HTTPS VirtualHost directives. Max-age is measured in seconds. This header is valid only on an HTTPS VirtualHost and performs the HTTPS request for one year, including sub-domains.

You should add server-side redirects to update non-HTTPS connections the first time the site is accessed. Add this rule to the non-HTTPS VirtualHost .

NGINX

Add this rule to the HTTPS configuration of your NGINX server block on Ubuntu server .

Strict-Transport-Security: max-age = 10886400; includeSubDomains

  • max-age: value indicated in seconds
  • includeSubDomains – optional value

Browsers remember, for the period specified in the max-age parameter, that they must automatically request resources in HTTPS for all the site and sub-domains.

  • HSTS eliminates the need to set up HTTP → HTTPS redirects

Allow Googlebot to crawl URLs in HTTP and HTTPS

  • Don’t block HTTP URLs with robots.txt

Don’t tag HTTPS URLs Noindex

Avoid meta robots, X-Robots and directives tags that can prevent Googlebot from reading the page.

HTML

HTTP

Update canonical links by pointing them to HTTPS resources

Remember to correct internal, external links and tags (canonical, alternate, …) by making them point to the HTTPS URL.

Google Search Console

  • Register all variants of the site in GSC by registering all profiles (www, not-www, and possibly https and mobile m.example.com)
  • Monitor “Index Status”
  • Monitor “Crawl Errors”

Registering all the profiles allows to analyze and diagnose every single sub-domain through GSC, from the scan statistics, the indexing of the sitemap, to the query data.

Scan statistics in the two profiles registered in GSC, before and after the migration to HTTPS

summing up

  • TLS: encryption, authentication and data integrity
  • TLS isn’t slow if you optimize your development environment
  • TLS can improve page loading by using fewer resources
  • Implement HTTPS on all sites and on all pages
  • Update links in content, implement redirections and HSTS
  • Send consistent signals to Googlebot

Considerations by Maurizio Ceravolo

Maurizio Ceravolo’s comment

I would like to add a few small considerations to Giovanni’s excellent article.

Personally, I have no plans to switch any of mine to HTTPS. For everything I always try to evaluate the cost / benefit ratio of each action. Passing a site in HTTPS has a cost, in terms of work and SEO damage that can be done if you do not follow Giovanni’s advice. For me, encrypting information if there is no sensitive user data doesn’t make sense. As it makes no sense to chase Google in its recommendations rewarded with a hypothetical improvement in the ranking.

Taking a practical example, if a customer is a restaurant, how can I justify the higher cost of passing the site in HTTPS? Does the user care if a hacker intercepting the wifi traffic sees that he is looking at the photos of the peppered with mussels? Considering that the average user has a public social profile and shows everyone when he is on vacation including thieves, I don’t think privacy can be his concern. At least until the house is burgled.

All this there is therefore only one reason why it would be better to bring the restaurant site in HTTPS: Analytics.

This HTTP protocol specification http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3 says:

Which means browsers don’t pass the referrer when switching from HTTPS to HTTP. And this has a consequence for Analytics. Traffic received from HTTPS sites is not recognized as a referral, but rather as direct traffic . And so this offsets the data we analyze. The only way to have the correct data is to also pass our site in HTTPS.

It must also be said that HTTPS does not only bring security benefits. But also some problems. HTTPS makes it more difficult to detect malware passing through advertising channels. That is, hackers buy advertising on some circuit and maybe upload a flash banner that spreads something malicious. If the advertising circuit is HTTPS, detecting these things is much more complicated.

The last consideration I would like to make is on what might be the spread of HTTPS. I am lucky to be able to share some data. For those who don’t know me, I’m a serial data downloader and I love building information databases. In my activity I have also downloaded all the Italian files of Google MyBusiness to do some analysis on them. Thanks to these data, for example, a couple of weeks ago I wrote an article on the adoption of cookie law by Italian companies . And shortly after I published this post on Google+ going to search on the sites of the previous analysis how many had been punctured.

We can therefore try to see my MyBusiness data to understand if Italian companies are adopting HTTPS. And the data is interesting because it is the Italian companies that make the bulk of the turnover for web agencies and freelancers in the sector.

The Italian MyBusiness cards I found are 2,339,556. Of these, 708.454 indicate a url on the card. Of these urls, excluding those that indicate a page on a social network as their site, how many are those in HTTPS? Very few. They are only 3,266. We are talking about less than 0.5% of Italian companies that have a site according to My Business. If we examine it, the data is even less.

These 3,266 cards often share the site. For example, there are 240 Total Erg distributors that refer to the same site as the parent company. And the same thing happens for bank branches (and if they didn’t use HTTPS, it would be downright dangerous). If I go to count the different domains we only have 455 . And these 455 are mostly big company sites. There are therefore few small and medium-sized websites (the typical customer of us professionals in the sector) that adopt HTTPS.

RELATED ARTICLES

Most Popular

Recent Comments