What Are the Advantages and Disadvantages of Converting a Website to a Secure HTTPS?
Do you also ponder whether it makes sense to move your website from the so far used HTTP protocol to a secure HTTPS? Would you like to learn beforehand what is ahead of you if you do so?
Switching to HTTPS is definitely not a simple thing. That’s why you should weigh all the pros and cons beforehand. This article summarises of all possible pitfalls a transition to HTTPS can cause, along with a list of the main reasons why (not) to go for the implementation of HTTPS on your site.
To start with, let’s sum up what HTTPS is.
What it is HTTPS?
HTTPS (Hypertext Transfer Protocol Secure) is a superstructure above HTTP (Hypertext Transfer Protocol), Internet communication protocol, which is used to transfer data on the Internet.
You have probably already come across HTTPS. Yet, you may simply not be aware of it. The easiest way to identify if a site is using an HTTPS protocol is to check the link bar, where would be a picture of a green locked padlock.
Fig. 1 - Sample link bar with an HTTPS protocol
What Is the Difference between HTTP and HTTPS?
HTTPS differs only by the data being encrypted during the transfer between the server (the website you want to view) and the client (your browser).
This substantially reduces the possibility to tap, monitor or modify the information. HTTPS also verifies the counterparty (to see who actually sends the data). This enables the users to know who they communicate with, and that no one is trying to deceive them.
However, even the use of HTTPS does not mean that communication cannot be tapped or modified in some manner. But it is significantly more difficult to do so when MITM method is employed,
Note MITM (man-in-the-middle) is a method of attack on security. Such an attack is usually caused by an attacker who is an intermediary between two communicating users. S/he taps all the communication, and sends its encryption keys to both parties, which help gain access to the contents of encrypted messages, and subsequently change them. Either of the users may not be aware of the existence of such an intermediary. Having said that MITM implementation requires additional action taken in the network infrastructure, through which the user connects to the server (usually to manipulate the routing tables of IP or DNS, i.e. so-called DNS spoofing).
SO HOW DOES HTTPS WORK?
Securing a system with HTTPS is done through a TLS protocol, which is based on certificates and trusted certificate authorities. These certificate authorities are institutions from whom are obtained trusted SSL certificates.
Anyone using a secure protocol needs to have "installed" a list of trusted authorities or certificates of their counterparties in their system. These are the parties they trust and are willing to communicate with (i.e. trust them).
By default, an operating system of any ordinary user contains some trusted root certificate authority (such as VeriSign and Comodo). Web servers you communicate with have certificates signed by such trusted certificate authorities.
So much about it in a nutshell.
Certificate authorities are credible institutions that issue certificates. The price of such a commercial certificate depends on the level at which the company is "in the whole food chain".This is owing to the fact that the company needs to spend appropriate funds to acquire its own certification. Following this is also specified the company’s margin from certificate issuance.
Certification companies can grant permission to other companies to issue certificates, and thus make them certificate authorities that sell certificates (usually at lower prices). These can then spread such an authorization further and resell.
The certificate price, therefore, varies depending on the entity from which you are buying the certificate. Generally, the longer the authority exists the more expensive the certificate.
Note: Your certificate can be trusted even if it is not directly signed by a trusted certificate authority. This can be achieved through an intermediary - another certificate authority. For example, if there is a generally recognized certificate authority A, which signs a trusted root certificate of a certificate authority B, then you can consider the certificate from authority B a trusted one.
Broadly speaking, this "trust-path" can unlimitedly chain. This way you can easily get 3 more certificates, along with your original certificate, preparing a credibility path for your certificate.
This can cause problems when intermediated certificates, which are required to verify your certificate, are not listed in the correct order, or when any of these certificates are invalidated throughout the chaining.
Fig. 2 – certificate chaining: https://drive.google.com/file/d/0B-KTsSR1_beTSG4yandDeGZua0U/view?usp=sharing
Therefore it is good to aim to have as short as possible trust-path - this usually also affects the cost of the certificate.
Here you can check the correct deployment of an SSL certificate: