Nowaday many websites have that cool green lock icon and HTTPS, meaning HTTP over SSL, but what benefits does SSL provide ?
Every technology aims to solve a problem, so does SSL.
When users at home connect to a website like Facebook or Google, the messages sent between a web server and browser go through many devices such as routers, proxies. Any of them can be compromised, known as man-in-the-middle attack ( MITM ).
We need to deal with 2 problems :
- The data transferred is not secured and can be read/modified.
- Clients can’t be sure whether they are talking to the true server or someone pretending.
SSL-Secure Sockets Layer is a security protocol that creates an encrypted connection between a client and a web server.
SSL can :
- Secure messages transmission with encryption
- Verify Server’s identity by SSL Certificate
Let’s set an example, Alice is the client surfing the webs, Bob is the server, and Eve is the evil MITM attacker. Now let go into how SSL can help Alice and Bob.
The basic idea is : Alice and Bob can come up with a shared secret key and use a symmetric encryption algorithm like AES, DES, 3DES to hide their messages.
But, how can Alice/Bob exchanges that secret key securely with Eve watching ? The answer is asymmetric encryption.
Asymmetric Encryption is a form of encryption with 2 keys : public key , which may be openly distributed, and private key , which is known only to the owner. Data encrypted by either key can only be decrypted by the other.
Upon initial contact, Bob sends Alice a SSL certificate , which contains his public key and some meta data (we will discuss it in Verify Server’s identity section).
Alice then can generate a shared secret key, encrypt it by Bob’s public key and send to Bob, only Bob can decrypt using his secret key , Eve cannot.
Now both side have securely exchanged a secret key, and can start using symmetric encryption.
Q : Why not just use asymmetric encryption all the way ?
A : Performance, asymmetric encryption requires more computational cost.
As said earlier, Alice receives Bob’s public key via SSL Certificate. So is it vulnerable to Eve MITM attack ? Short answer : technically, Eve cannot attack it, Alice can verify and decide to trust the certificate or not on client-side.
SSL Certificate is a digital document issued to Bob for his domain by a trusted 3rd-party, called CA-Certificate Authority.
The SSL certificate has Bob’s public key and meta data (domain, organization, …). The CA validate those information and ensure the public key in the certificate match Bob’s private key, then sign it with their private key, creating a Digital Signature which prevent any changes to the certificate later.
Digital Signature is well described in the following picture :
If Eve tries modifying the public key, she won’t be able to generate a new signature. Later, Alice just need to use the CA's public key to validate the signature, if it's valid then the certificate is indeed from BOB and hasn't been changed.
Where can browsers get CA’s public key to verify the signature ?
It's already in the client browser or OS.
CA have their own certificate containing the public key that browsers can use to verify their Digital Signature on website’s SSL certificates.
There are Root-CA and Intermediate CA.
- Root-CA : default set of trusted CA, their certificates are called root-Certificate and stored within Alice’s browsers or OS. Browsers can locally get their public key. The root-CA signed their own certificate, in other words, self-sign.
- Intermediate CA : Can be considered child CA. Their certificates are signed by root-CA. They can also signed website’s certificates normally or can issue another child node. If signed by an Intermediate CA, Bob need to provide Alice all the Intermediate CA Certificates (recursively) along with his own SSL Certificate, the root-CA is excluded since Alice already have it. That will form a chain of trust.
Websites get the awesome green lock if the certificate’s chain of trust lead back to a local root-CA, otherwise browsers will show warning “Certificated not issued by a trusted CA”.
For example, you can check your self, StackOverFlow ’s certificate is signed by Let’s Encrypt — an intermediate CA, and its certificate is signed by Digital Signature Trust Co — a root CA.
Oh, now I have to mention that there’s no free lunch, and you probably have to pay to get it, one place to check is Digicert.
But you like free stuff, it’s make sense you want to test before actually spending, Let’s encrypt is a good free solution, the drawback is their certificate only last 3 months, then you will have to renew.
Of course CA can be compromised and may cause security risks, but that’s another problem.
That’s all, since I want to keep it short, I tried not to go too far into any small areas, but I did my best to have the keywords included.