HTTPS From HTTP: How And Why You Need To Migrate
The sooner the better. Don't just sit there, read on to find out why you need to migrate over to HTTPS if you haven't already.
Join the DZone community and get the full member experience.Join For Free
we don’t hang out on the internet anymore. we live on the internet. just like our physical world, the internet is a funny place – at times quirky, at times it’s random, and at times it’s safe. well, we think it’s safe. as developers and website owners, we are responsible for providing a safe web experience to all of our users.
as users ourselves, we have seen it all:
- malware injections
- popups triggering software installs
- trojan horse viruses
building trust and credibility with users goes a long way. and it is because of this, global leaders such as mozilla and google are putting their weight behind making the web a more secure place. this is contributing to the major reason for a gradual shift from http websites to https websites.
understanding the major difference?
before we dive deeper, let’s get a quick understanding of http and https. these are the most frequently used protocols on the web.
- http : hypertext transfer protocol – a simple protocol for sending and receiving text based messages.
- https : hypertext transfer protocol secure – the same protocol as http, but the text is encrypted.
how https bridges the gap
google (and many others) are committed to making the web more secure for all the users. in 2014, google had their https everywhere campaign when they announced https as a ranking signal and started indexing secure pages over unsecured pages .
google’s indexing conditions:
- it shouldn’t contain insecure dependencies.
- it isn’t blocked from crawling by robots.txt.
- it shouldn’t redirect users to or through an insecure http page.
- it shouldn’t have a rel=”canonical” link to the http page.
- it shouldn’t contain a noindex robots meta tag.
- it shouldn’t have on-host outlinks to http urls.
- the sitemap lists the https url or doesn’t list the http version of the url.
- the server has a valid tls certificate.
the first condition is a critical requirement. the page should not include “insecure dependencies.” many pages include insecure images, embeds, videos, and so on.
- google has even created their own guide, “ securing your website with https “ .
according to the data from builtwith, around only 6.3% of the top 100,000 websites are using ssl .
some additional benefits:
- more security – a major reason why it is important to be running over https is of course because of security! the reason you need an ssl certificate for e-commerce and other transactional sites is because they are processing sensitive information. for other sites, a big reason for going to https is the wordpress login page. if you aren’t running over an https connection, your username and password are sent in clear text over the internet. anyone can sniff and capture wordpress logins over unsecured connections using a variety of free tools .
- better referral data – another good reason to migrate is that the referral data is blocked in google analytics. if your website is on http and you go viral on any https website, the referrer data will be completely lost and the traffic from the https website could end up under “direct traffic” (which is not very helpful). if someone is going from https to https, the referrer will still be passed.
- ssl builds trust and credibility – to move to this secure protocol you need an ssl certificate. an ssl certificate builds trust and credibility with your visitors. visitors tend to look for the green padlock on a website. this gives it “ ssl trust ”. it is important to let your visitors know you are a secure site and that their information will be safe.
common myths around the migration
let’s go ahead and bust these myths.
- my site’s not important enough.
more than often, publishers maintain that their properties don’t handle sensitive user data (login info, payments, etc.) so they can do away with https.
- read here about how isps including airtel and mtnl have indulged in such activities .
moreover, running on http restricts web developers from using key apis including:
- geolocation: you can no longer seek a user’s location if you are on http.
- web push notification: push notifications are only available on https.
- getusermedia: you can no longer trigger permissions of using a user’s camera/microphone if you are on http.
- http/2: all major browsers support http/2 for https.
- eme and app cache: to be removed soon.
- https will slow down my site.
quite a few developers have witnessed negative results post migration to https. having said that, when gmail was migrated to http in 2010, there was no noticeable performance impact.
here are the stats from the gmail’s migration:
negative results are often because of a lack of optimization such as moving to http/2. we have to update the way that we talk about https and performance.
- i can move my site to https, but what about the 3rd parties i depend on?
another major concern for publishers is with reference to the third party content on their website – primarily ads [most often the only source of monetization].
a key constraint with this is, if you move to https, all of your content (including third party content) also has to be served over https.
note : google adsense and ad exchange requests are already being served over https.
there is also the concern about partnerships wherein 3rd party service providers depend on the http referrer header. when a user follows a link from an https site to an http partner site, browsers will strip their referrer header for privacy reasons. there’s a web platform feature called “ referrer policy “ that helps with this.
publishers can set a referrer policy to allow their partners to see which traffic is coming from their site, but they won’t see the full url that the user was visiting, so user privacy is maintained.
then there is a kind of general problem called mixed content. mixed content is the problem of loading non-secure http content on https. this is important because non-secure sub-resources can actually compromise the security of a secure https site. browsers will actually block this content and completely wipe out all of the security of that https site.
publisher websites (i.e. blogs) contain a lot of old news articles that link to third party images which aren’t available over https. these images are called passive content and browsers will still allow them to load.
the https site won’t be completely broken, but that green lock will go away.
this header is basically a way for publishers to assert to the browser that all content should be loaded over https and that the publishers want to receive reports about any content that isn’t. content security policy allows publishers to find and fix mixed content across their properties. chrome also has a devtools security panel to make it as easy as possible to find and fix problems with https configurations such mixed content issues. essentially, third party providers must support https in order for you to fully move your site.
frequently asked questions
- how does this whole communication take place?
when a client/browser requests for a secure session over https, the server responds with the ssl certificate.
a request is made from the client end and the server responds with the certificate and the server’s public key. the client/browser then checks the validity of the ssl certificate signed by ca. then the client/browser sends an encrypted session key with the server’s public key. now the server de-crypts the session key with its private key.
with this, a secure session is created for a secure data transfer.
- how is the data sent over https secured?
data sent using https is secured via transport layer security protocol (tls), which provides three key layers of protection for your information:
- encryption – encrypting the exchanged data to keep it secure from eavesdroppers. the encryption ensures that while browsing, no one can intrude into conversations, track activities across pages, or get access to any information.
- data integrity – this means data cannot be compromised during transfer and any alteration made to the data cannot be easily detected.
- authentication – this ensures that users are on the correct website. https authentication protects against man-in-the-middle attacks and builds user trust.
getting your ssl certificate
there are numerous options that can be availed to get an ssl certificate while moving from http to https.
here are three great options:
|sslmate issues single-domain certificates for $16/year .refer to the guide for installing the certificates and setting up with other common hosts .|
– get your
ssl certificate from let’s encrypt! you can choose a number of options from their available certificates. domain validation: single domain or subdomain, no paperwork (just email validation), cheap, issued within minutes.
business/organization requires business verification and provides a high level of security, issued within 1-3 days.
extended validation : requires business verification which provides a higher level of security, issued within 2-7 days.
|aws certificate manager (acm). these certificates are free and issued directly by amazon and last a little over a year. however, they currently require manual issuance through email validation, and do not support certificate transparency . here’s a good acm guide for jekyll .|
things to do while making the switch
first of all, buy and activate an ssl certificate if you haven’t already. during the migration, there could be some hurdles stalling the process. errors may occur when google starts crawling the http version of your website and generating content duplication issues, with both https and http versions of the pages shown and different versions of the page showing on http and https.
check out these other common pitfalls in using https/tls .
best practices when migrating to https:
- using robust security certificates. as part of enabling https for your website, you must obtain a security certificate (ssl certificate). the certificate is issued by a certificate authority (ca) which takes steps to verify that your web address actually belongs to your organization. while setting up your certificate, ensure a high level of security by choosing a 2048-bit key. if you already have a certificate with a weaker key (1024-bit), an upgrade would be a great way to go.
- redirect your users and search engines to the https page or resource with server-side 301 http redirects.
- use a web server that supports http strict transport security (hsts) and make sure that it’s enabled.
the idea behind the whole migration is to provide a safer web experience, ensuring your personal information stays private and does not get misused.
anything and everything could be personal to you or your end users.
even if you are searching for “nexus 5 cost in india”, that search could be private to you. whether you are browsing or looking for a product or reading an article, you generally do not want what you’re doing to be public information. particularly for personal information, banks, and transaction information, https has become a necessity and an industry standard.
though the migration is highly recommended and being followed by most website developers, the final decision depends on you. for those who are ready to follow this safer web practice, get started by grabbing your ssl certificate and be delighted to have that green padlock on your website.
have you made the switch yet? let me know in the comments.
Published at DZone with permission of Ruchika Sharma. See the original article here.
Opinions expressed by DZone contributors are their own.