TLS and Web Certificates Explained

TLS stands for 'Transport Layer Security' and it's basically derived from SSL. TLS is a protocol which works on the transport layer, hence the name.

As we know, communication security is a primary concern, so correct implementation of TLS extends web security to the next level. In a TLS implemented environment, if an intruder tries to attack, at most he may know the host information which you are trying to connect, what kind of encryption is being used, or may be able to terminate the connection, but he can't do much.

In almost all communications protocols, there are three major parts: data encryption, authentication, and data integrity.

In this protocol, data encryption can be achieved in two ways, either using Public-Key Cryptography or Symmetric Keys. Public-Key Cryptography is a better implementation than Symmetric Keys.

Quick Overview of Public-Key Cryptography and Symmetric Keys

Public-Key Cryptography, also known as Asymmetric Cryptography, uses the public-private key. So the public key B is getting used to encrypt the, data A, (B shared the public key to A) and after receiving the encrypted data, B decrypts it using its own private key.

Symmetric-Keys Cryptography uses the same key for encryption and decryption, hence B and A both have the same secret key, and can encrypt/decrypt messages using this key. Since the same secret key is used, this is kind of a drawback.

Now let's see how authentication works in TLS. Authentication can be achieved using digital certificates, and this is to ensure that a user sending a message is who he/she claims to be, and to provide the receiver with the means to encode a reply. Operating systems and browsers maintain lists of trusted certificates so they can verify.

Trusted vs. Untrusted Certificates

Digital certificates can be of these two categories. Trusted Certificates are signed by a CA (Certificate Authority) while Untrusted certificates are self-signed.

Trusted Certificates

A trusted certificates resides at a web browser and is signed by a CA. This is to ensure the highest level of trust. Let us say a website, 'xyz.com', wants to have a trusted digital certificate from a well-known certificate authority 'Comodo'.

The steps are as follows:

• Create a web-server for my web application: xyz.com

• Created a secret-key pair (public-private key) using Public-Key Cryptography (since it's more secure)

• Generate a Certificate Signing Request (CSR) to certificate authority, in my case it is 'Comodo'. The file name could be 'certreq.txt' in your disk.

• Create an application to certificate authority, and include the CSR.

• Certificate Authority ('Comodo' in my case) will validate your request including your public-private key.

• If it's all good, the CA will sign the request using it's own private key.

• CA will send back the certificate and we need to install it on our web-server.

• Now it's all done.

Untrusted Certificates

An untrusted certificate is signed by the owner of the site, and this used when trust concerns are minimal.

In TLS implementation, a trusted certificate is advised over an untrusted certificate.

How the TLS Certificate Exchange Works

• Open the url 'xyz.com' in a browser

• The web server receives the request.

• The web server responds back with a certificate to the request

• The web browser evaluates the response and validates the certificate.

• The web browser learns during validation that the certificate is signed by the CA 'Comodo'.

• The web browser will check its certificate database (for example: IE -> Internet Options -> content -> certificate) for 'Comodo' certificate.

• Once found, the web browser will use the 'Comodo' public key to validate the certificate sent by web server.

• If validation is good, then the web browser will consider this communication to be secure.