When you see a little green lock with the word ‘Secure’ to the left of a URL, you’re likely to assume the site is safe. Ditto for the words “this site uses a secure connection”
or a URL beginning with the letters ‘https’.
Often time I have experienced that people treat HTTPS communication thing as some sort of blackbox that they don’t even want to try to understand because it sounds so complicated, but it’s actually pretty simple.
Whenever you hear HTTPS and cryptography and all, it all sounds very complex and very mathematical, but it doesn’t need to have to be complex at all.
You just need to trust that public-key cryptography & signature works. Now if you are saying what is public-key cryptography and signature, it basically a couple of very simple mathematical functions that only work one way or the other, much easier to compute in one way than in another way. But you should trust these two principles:
1. Any message encrypted with Tom’s public key can only be decrypted with Tom’s private key.
(Basically, that means the only tom because he is the only owner of his private key can decrypt any message even though it can be publically distributed and anyone can view it but can do nothing as they see just some random gibberish)
2. Anyone with access to Jerry’s public key can verify that a message (signature) could only have been created by someone with access to Jerry’s private key.
(Basically, this means, anyone on the internet even though they don’t know Jerry’s private key, can verify that a message was sent by Jerry)
In the background there’s a bit of multiplication and modulus calculation going on, but you don’t have to worry about that at all.
How HTTPS Work? 🤔
Based on this we can start our own test to see how all of this works.
Now we can start with your browser and let’s say you want to access google.com, so the first thing your browser does, it tells the internet give me google.com.
This is of course very simplified, in the background, there will be a DNS request going on so that you can resolve that name to an IP address and then it will be routed through many computers until it reaches google.com. But in essence your computer says give me google.com.
Now Google will then respond saying “Hey, sure, here’s my certificate. This certificate contains my public key and it was signed by Google Certificate Authority(CA)”.
Your browser then says “oh, I know and I trust google, I also know Google CA’s public key, so I will verify if this certificate was actually signed by Google CA.”
Since we assume everything is fine, there is no attack going on, your browser then says, “Hey, google.com I trust the google CA, and it looks like you are indeed who you say you are. Because I trust you I have created a new secret key and encrypted it with your public key.”
So remember when you encrypt something with a public key only the owner with the private key can decrypt it.
Google.com then say “Hey browser, smart choice. Only I have my private keys and can decrypt this.So now I have this secret that you just randomly created as well.”
So now the both parties realize, we are the only two machines on the entire internet who know this new secret key. From now on let’s encrypt all our communication with this secret key.
So based on the principles we have trusted before we have now created a secure communication channel between your browser and the server in this case google.com, even though the entire communication was public.
Someone could be listening to this entire communication happening and they won’t be any wiser as the whole thing is encrypted. To an outsider everything will be giberrish.
But all of this wouldn’t be possible without the certificate authority and understanding how is a certificate signed. For that wait for my next article on Certificate Authority(CA).
And I would like to show you how it works with this simple explanation.
While more and more sites are switching to HTTPS, those ‘secure’ symbols don’t
guarantee that a website is safe from all threats.
A phishing site, for example, can legitimately display that comforting green lock next
to its ‘https’ address.
The green lock means that a site has been issued a certificate and a pair of
cryptographic keys have been generated for it, encrypting any information transmitted
between you and the site.
Like in our case we are using COMODO CA certificate for HTTPS connection.
if you click on the ‘more information‘ in Firefox it will show you detailed information about the certificate and used encryption algorithms.
The problem is that the green lock and the issued certificate.say nothing about the site
itself.
I will highly recommend you to watch below YouTube video to understand What are certificates?
A phishing page can just as readily get a certificate and encrypt all traffic that flows between you and it. Put simply, all a green lock ensures is that no one else can spy on the data you enter. But your password can still be stolen by the site itself if it’s fake.
You are easily able to check Spam Website with www.scamadviser.com, it will show you the trust rating of that website.
We are recommending Avast Internet Security (View on Amazon ) or McAfee (View on Amazon ) to our Readers for internet security.
If the address bar shows no lock at all, that means the website does not use encryption, and any information it exchanges with your browser uses standard HTTP.
Although Google Chrome has started tagging such websites as unsafe, they might, in fact, be squeaky clean–they just don’t encrypt traffic between you and the server.
I will recommend you to read An overview of Transport Layer Security (TLS) 1.3 if you are looking for depth knowledge of HTTPS.
However, most website owners don’t want Google to label their websites as unsafe, so more and more are migrating to HTTPS.
In any case, entering sensitive data on an HTTP site is a bad idea because anyone can spy on it.
If you want’s to Test Your site’s certificate and configuration, browser SSL implementation and How other websites are doing, just visit https://www.ssllabs.com/
Does a padlock icon mean a site is completely safe to use?
In fact, the majority of web applications are insecure, despite the widespread
usage of SSL technology and the adoption of regular PCI scanning. Visit Open Web Application Security Project to find the Top web application attacks.
Broken authentication:- This category of vulnerability encompasses various defects within the application’s login mechanism, which may enable an attacker to guess weak passwords, launch a brute-force attack, or bypass the login.
Broken access controls:- This involves cases where the application fails to properly protect access to its data and functionality, potentially enabling an attacker to view other users’ sensitive data held on the server or carry out privileged actions.
SQL injection:- This vulnerability enables an attacker to submit crafted input to interfere with the application’s interaction with back-end databases.
An attacker may be able to retrieve arbitrary data from the application, interfere with its logic, or execute commands on the database server itself.
Cross-site scripting:- This vulnerability enables an attacker to target other users of the application, potentially gaining access to their data, performing unauthorized actions on their behalf, or carrying out other attacks against them.
Information leakage:- This involves cases where an application divulges sensitive information that is of use to an attacker in developing an assault against the application, through defective error handling or other behavior.
Cross-site request forgery:- This flaw means that application users can be induced to perform unintended actions on the application within their user context and privilege level.
The vulnerability allows a malicious web site visited by the victim user to interact with the application to perform actions that the user did not intend.
I will recommend you to read The Web Application Hacker’s Handbook and The Browser Hacker’s Handbook for more information on Web applications attacks and security.
Conclusion
SSL is an excellent technology that protects the confidentiality and integrity of data in transit between the user’s browser and the web server. It helps defend against eavesdroppers, and it can provide assurance to the user of the identity of the web server he is dealing with.
But it does not stop attacks that directly target the server or client components of an application, as most successful attacks do.
Specifically, it does not prevent any of the vulnerabilities just listed, or many others that can render an application critically exposed to attack. Regardless of whether they use SSL, most web applications still contain security flaws.
