When Must HTTPS and SSL be used?
Communicating over Secure Sockets Layer (SSL) or HTTPS is a most for a lot of web applications. I’ve seen many applications developed securely but deployed poorly simply because administrators sometimes do not realize the importance of HTTPS. In this article I am going to introduce the infrastructure HTTPS provides and case studies that HTTPS is a most for them. Moreover I am going to talk about several attack scenarios that are possible at the absence of HTTPS.
HTTPS protocol provides encryption and a form of identification. When a website uses HTTP for communication all of the traffic between the server and client are in plain text; this means an attacker can read all the communicated data between the sender and the receiver by performing a typical Man-In-The-Middle attack. HTTPS provides a form of the identification too. That being said, the user can see if the website is really the one it claims to be. As a matter of fact, this way the website owner provides a form of defense against forgery attacks.
Any website which communicates a form of critical data should communicate over SSL. A typical example is a website which has Authentication and Authorization mechanisms. Such a website should not only use HTTPS for the login page but also for every following page after the authentication. Generally other pages can be overlooked for HTTPS communication but this is no true for all situations. As a rule of thumb you should have in mind that each and every pages of your website which is not communicated over SSL can be a target for a forgery attack. In this form of attack, the attacker imitates your website and shows a mocked version of your website to the user. This way he or she can show false information that may lead to other forms of attacks.
Let’s start with the first attack scenario when none of the website pages are communicating over SSL. In this scenario a website user wants to login in an internet café. A malicious user of this internet café has run a Sniffer tool and sees all the traffic which is communicated in the network. After the website user enters the user and password the attacker sees the communicated credential in plain text and use it for malicious activities.
In the second scenario the website just communicated the login page over SSL. In this scenario the attacker cannot see the user and the password because they are encrypted but he can perform another form of attack: session high jacking. In this form of attack the attacker waits for the user to login and after that he sniffs a token in the header of the communicated traffic. This token is the Cookie-Session token and presents the identity of the user to the website. The attacker can resend this token to the website and mimic the user. In the next step he can change the password or performs a malicious activity. It should be noted that if other pages after the login is also communicated over HTTPS, this form of attack is not possible.
For HTTPS communication a certificate is needed. This certificate should be signed by a valid authority and the website owner should pay annually to renew this certificate. In some cases owners avoid buying a certificate and they themselves sign the certificate. When the certificate is valid, the browser checks the DNS name of the website (the address shown in the browser) with the certificate owner and inform you if these two are not identical. You may run to pages that the browser asks you either to terminate the session or confirms the identity of the website, this happens when the certificate is not valid. Although even if the certificate is not valid the previous attack scenarios are not possible, the attacker can still impersonate the website identity and performs another forgery attack. In this case you run to the same page browser would show if it was from the original website so you have no way to check the validity of the request!