How SSL works?
SSL is known as Secure Socket Layer. This layer is used to securely communicate over the internet, it does so by encrypting the communication data between two points. Generally, one point being web browser and other being Web Server. No other point/node on the network can decode it or it would take them thousands of year to decode it. Thus, preventing men in the middle attack and giving a secure connection between web-browser and web-server.
Why do we need encryption?
Let’s say browser wants to send a message or data to web-server. If the message is not encrypted and present in the plain format then anyone on the network can eavesdrop or see the message over the network and can also change the content of that message. This is called a man in the middle attack. So, if anyone in the middle over the network changes the data then data sent by the client will be different than the data received by the web-server and vice versa. This data message may include credit card details, username and password etc., which is sensitive data and shouldn’t get disclosed and since data travelling without encryption can be seen by anyone on the network which can correspond to data theft. This is why we need encryption. Using different types of encryption techniques, messages can be encrypted and it can only be decrypted by whom it’s meant to be. In some of the encryption techniques, the message cannot be decrypted even by whom it has been encrypted.
How does encryption work?
Let’s say Bob wants to send a message to Alice. Since sending a plain message is not secure, he decides to encrypt the message before sending it to Alice. Now bob has several choices for encryption. Generally, there are two types of encryption: Symmetric Encryption and Asymmetric Encryption.
In symmetric encryption, it uses algorithms such as AES, in which one key is used to encode and the same key is used to decode. So anyone with this key can encode it and decode it. Here, only one key is used by both Bob and Alice to encrypt and decrypt the message. Anyone with this key can decrypt the message so only Bob and Alice should have the key in order to do secure communication.
Whereas in asymmetric encryption, we use algorithms such as RSA, in which both public and private key of Bob and Alice are used to encrypt and decrypt the message. So, let’s say B(public) and B(private), A(public) and A(private) are the public and private keys of Bob and Alice respectively.
Here, for Bob and Alice to communicate using Asymmetric encryption, Bob must have the public key of Alice (A(public)) and Alice must have the public key of Bob(B(public)).
If Bob has to send a message to Alice, then Bob uses the public key of Alice A(public) to encrypt the message and Alice uses her private key A(private) to decrypt the message. The algorithm used in asymmetric encryption has characteristics that no one in the middle can decrypt Bob’s message because A(private) is required to decrypt the message. And since, A(private) is Alice’s private key, no one except Alice has this key unless Alice shared it.
Public and Private key pair are mathematically linked to each other and are generated using algorithms such as RSA. Even though they are mathematically linked to each other but they can’t be derived from one another which means if someone has the public key of Alice then they can’t derive a private key of Alice from it. Any message encrypted using one public key can only be decrypted by private key linked to that public key using which it was encrypted.
The problem in a key exchange between Alice and Bob?
Now, Bob and Alice can use two types of algorithms for encryption and decryption i.e, Symmetric Encryption and Asymmetric Encryption.
If both Bob and Alice decide to use Symmetric Encryption then they both must have the same key, so now how do they get this key? One way could be that whenever Bob and Alice want to communicate then either of them can send this key to another one and both can use this key for encryption and decryption of messages while communication.
It’s simple, but we have one major problem here which is, let’s say a FakeBob/FakeAlice(let’s name it Ron) is sitting between Alice & Bob over the network and Bob is sending a key to Alice so that they can start secure connection but Ron who is in the middle sniffed the key sent by the Bob and sends his own key (Ron’s Key) to the Alice. Now, Alice will assume that this key is shared by Bob but it’s not. It’s shared by Ron. Now, every message sent by Bob to Alice can be read/changed/altered by Ron on the network because Ron has the key to decrypt it and similarly, Alice receives the message altered by Ron assuming that Bob is sending this message.
Similarly, when Alice sends a message to Bob it can be read/changed/altered by Ron because Alice is encrypting the message using Ron’s shared key assuming it as Bob’s shared key and in between them over the network Ron sniffs the message sent by the Alice, decrypts it and generate a new message for Bob using Bob’s shared key which is present with the Ron, now Bob assumes that the message is coming from Alice but actually, it’s Ron message. This is called a man in the middle attack and it is a big security issue.
Similarly, in the case of Asymmetric Encryption, Bob must share his public key with Alice and Alice must share her public key with Bob but when they share it over the network then some men in the middle could change the key and can send their(Ron) own public key to both Bob and Alice. When Bob shares his public key then Ron sniffs his public key and send his own public key to Alice and similarly when Alice sends her own public key to Bob then Ron sniffs this key and sends his own key to Bob now Ron has the public key of both Alice and Bob and Alice has the public key of Ron which she is assuming as Bob’s public key and similarly, Bob receives the public key of Ron and assuming it as Alice’s public key.
Now Alice encrypts the message using Ron’s public key assuming it as Bob’s public key and sends it to Bob but in actual it’s Ron Public Key and now Ron who is sitting in between the network sniffs the message coming from Alice for Bob and then he decrypts it using his own private key(R(Private)) and make a new message for Bob using Bob’s public key and sends it to Bob and now Bob assumes that this message is coming from Alice which in actual it's not and now Bob decrypts this message using his own private key and gets the message sent by Ron. The same thing happens when Bob’s sends the message using Public Key of Ron assuming it as Public key of Alice. Here, both Alice and Bob are not sure if they are receiving the correct data, public keys shared by one another, so to check the authenticity of the public keys and to build this trust between both of them we use Certificates.
How certificates work in setting up SSL?
Using certificates for setting up a secure connection builds the trust between two parties that the public key shared by someone actually belongs to them and not to someone else. Let’s see how it is done:
Whenever web browser wants to communicate with the server then the server sends certificates to the web browser. Then client verifies the authenticity of these certificates and if the certificates get verified then the client is sure that the public key present on the SSL certificate is server’s public key and starts sending encrypted data to the server using server’s public-key present on the SSL certificate. All the data sent by the client to the server will be encrypted using this public key. Now client send pre-master shared key to the server encrypted using the public key of server in order to complete SSL handshake (explained later) and starts a secure connection and browser shows a lock button on the Address Bar. If there are no certificates sent by the server or certificates didn’t get verified then the browser will not start the secure connection and will show “Not Secure” in the address bar.
How the browser verifies the authenticity of the Certificates?
Certificates sent by the server are Intermediate Certificate Authority(CA) Certificate and server’s SSL certificate. SSL certificate is digitally signed by the Intermediate certificate authority’s private key and Intermediate CA’s certificate is signed by the Root Certificate Authority(CA) using its Private Key. Each certificate has details on it. For example, an SSL certificate consists of the organisation’s information such as domain name, public key, organisation name, country, region, digital signature etc.
Similarly, an intermediate certificate authority certificate consists of information such as root certificate’s signature, region, country, issuer, expiry date, valid from date, name of Certificate Authority etc. And similarly, Root certificates consists of similar type of information such as expiry date, valid from date, organisation name, encryption algorithm details etc. The server doesn’t send Root certificate to the web Browser because Root Certificates are already provided by the operating system and comes with the operating system. And it is the Root certificate using which the authenticity of certificates sent by the webserver is checked.
SSL certificate is issued by the Intermediate CA and is digitally signed using Private key of Intermediate CA and since this certificate is digitally signed by the private key of the issuer then only the public key linked to that issuer’s private key can verify the signature present on the SSL certificate and since Intermediate Certificate Authority’s certificate consists public key it can verify the SSL certificate’s signature and can verify its authenticity. Similarly, the Intermediate Certificate Authority Certificate is issued by the Root Certificate Authority and is digitally signed by Root CA’s private key so only the valid public key can verify it. And since root certificates have public keys they are able to verify Intermediate Certificate Authority Certificate.
Why we use the Intermediate Certificate? Can’t we use Root Certificate directly to verify the SSL certificate?
We use Intermediate certificate instead of using Root Certificate directly, in order to add one more layer of security. Generally, root Certificate Authority offices are kept offline and their Private Key is kept offline with many layers of physical security with restricted access because if the private key of Root Certificate Authority gets compromised then most of the Internet will become Insecure — this is the worst security threat that one can imagine of. Because this private key can be used to sign unauthorised certificates and someone in the middle of the network can send these unauthorised certificates and browser will verify them and thinks that it’s a secure connection where actually it’s not.
If someone, in the midway on the network changed or modified the certificates and then sent it to the browser then it wouldn’t get verified by the browser because Root Certificate public key will not verify intermediate CA certificate’s signature and since it doesn’t get verified then the chain of trust gets broke and SSL connection will not be established and web browsers will show an insecure connection in the address bar.
How SSL certificates are issued?
SSL certificates are issued by Intermediate CA. It requires organisation document verification, domain verification etc for ICA to issue an SSL certificate.
Different Types of Certificates used:
1. Root Certificate Authority certificate
2. Intermediate Certificate Authority Certificate
3. SSL certificate
Root Certificate Authority is top-level Certificate Authority. Root certificate verifies Intermediate CA certificate by verifying the digital signature present on the Intermediate CA certificate and intermediate certificate authority verifies SSL certificate by verifying its signature. This is called a chain of trust. If any of the certificate in the chain is not verified then the chain of trust breaks and browser will not be able to give a secure connection.
Above, there are three certificates, DigiCert High Assurance EV Root CA which is a Root CA, DigiCert SHA2 Extended Validation Server CA which is an Intermediate CA and last medium.com SSL certificate. Here, DigiCert SHA2 and medium.com SSL certificate are sent by the server(in this case by Medium) and the Root certificate is already present on the machine to verify both certificates authenticity.
Here, DigiCert High Assurance EV Root CA verifies DigiCert SHA2 Extended Validation Server CA by verifying its Digital Signature and then DigiCert SHA2 Extended Validation Server CA verifies medium’s SSL certificate by verifying its signature on it. Now certificates have been verified by the browser and now browser check for the domain information on the SSL certificate and match it with the website Domain and if this matches then the browser is now confident that Public Key present on the SSL certificate actually belongs to Medium and not to someone else and starts the secure connection between the browser and medium server.
You can check for Root certificates on your machine. For mac, it is present in KeyChain. KeyChain -> System Roots -> Certificates.
After verifying certificates, the client now has the public key of the server and client can trust this key so now the client generates a pre-master key which client encrypts using the public key of the server and send it to the server using Asymmetric Encryption. The server now decrypts this message using its own private key and get the pre-master key shared by the client. Now both Server and Client perform steps to generate the master secret with the agreed cipher and both client and server exchange messages to inform that future messages will be encrypted using Symmetric Encryption. Now encryption being used changes from Asymmetric Encryption to Symmetric Encryption. This is called the SSL handshake.
Why encryption changs from Asymmetric to Symmetric Encryption?
Asymmetric Encryption is slow and takes time as compare to Symmetric Encryption and after successfully exchanging symmetric key using Asymmetric encryption using Symmetric encryption is as good and secure as asymmetric encryption because only the client and server have the shared key.
SSL Handshake
1. Client Hello
Information that the server needs to communicate with the client using SSL. This includes the SSL version number, cipher settings, session-specific data.
2. Server Hello
Information that the server needs to communicate with the client using SSL. This includes the SSL version number, cipher settings, session-specific data.
3. Authentication and Pre-Master Secret
The client authenticates the server certificate. (e.g. Common Name / Date / Issuer) Client (depending on the cipher) creates the pre-master secret for the session, Encrypts with the server’s public key and sends the encrypted pre-master secret to the server.
4. Decryption and Master Secret
The server uses its private key to decrypt the pre-master secret. Both Server and Client perform steps to generate the master secret with the agreed cipher.
5. Encryption with Session Key
Both client and server exchange messages to inform that future messages will be encrypted.
After SSL handshake, both client and server communicate over a secure channel using symmetric encryption.
This is how SSL works.