Friday 3 April 2015

SSL

In the earlier posts, we have discussed symmetric/asymmetric key infrastructure, digital signatures and Digital certificates.

Now we will cover how information exchange is made secure on web using SSL.
i.e. when you enter sensitive information like credit card details or bank login credentials, how is it ensured that data is transferred securely from your browser to server.

For this websites rely on HTTPS (Hyper Text Transfer Protocol Secure), which uses SSL (Secure Socket Layer).

If a webserver needs to communicate with client over https, it first needs to get a valid SSL certificate.

SSL Certificate:
It is a digital certificate that identifies the webserver (Organisation owning the webserver). It is issued by Certificate Authorities

For getting a SSL certificate you need to first create a CSR request. A CSR or Certificate Signing request is a block of encrypted text that is generated on the server that the certificate will be used on. It contains information that will be included in your certificate such as your organization name, common name (domain name), locality, and country. It also contains the public key that will be included in your certificate. A private key is usually created at the same time that you create the CSR (But is not sent to CA).
As discussed in the previous post, CA signs the information contained in your CSR request with their private key and provide you with SSL certificate.

You add the certificate on your web server. 

How SSL certificate creates a secure connection

Now lets see how secure communication takes place between browser and web server.




1. Browser requests a secure page (https:\\..) (or if it request for a secure page via http, webserver redirects it to https)

2. Web server sends its public key to browser via the SSL certificate.

3. As browser already have CA public key (CA Root certificate), it can decrypt the certificate and get web servers public key. It also validates that the certificate was issued by a trusted party and that the certificate is still valid and is related to the site contacted.

4. Once the verification is complete, browser uses the public key to encrypt a random symmetric encryption key and sends it to the server.

5. Server then decrypts the key using its private key and sends an acknowledgement back to browser.

This complete process is called SSL handshake, where browser and webserver exchanged a symmetric key.


6. Now both browser and server have exchanged a symmetric key and data can be exchanged securely between them by encrypting it with the symmetric key. As only browser and webserver have the symmetric key, no one else can read the secure data.

The reason to use symmetric key instead of directly using web servers public key to encrypt future messages is that symmetric encryption is faster than asymmetric key encryption. So we use asymmetric key to encrypt and exchange the symmetric key, and actual content is then encrypted by the symmetric key.


No comments:

Post a Comment