Security on the web – How HTTPS works using SSL

Use Case – Credit card Application

Let us consider the use case of the online shopping where credit card information has to be sent over the internet to the server. To begin with let us use plain HTTP.

As shown above, the sensitive data, the credit card information of a person, sent over the internet data is insecure since security is not applied(i.e. HTTPS is not used).
Because of the nature of internet, the data doesn’t directly go to the server, but passes through routers, servers and other computers. This is shown below :

Any person with notorious intent who has access to any one of these intermediate computers can peek into the data being sent and thus can potentially steal the sensitive data. This is shown below :

Another problem that can arise is that if someone spoofs the server website and tricks the user into revealing the data. The user doesn’t know whether he is talking to correct server or not, i.e. who is at other end. Thus the identity of the server is also not confirmed. This is shown below:

How do we secure the data being sent over the internet?

To secure the data sent over the internet, HTTP protocol is not sufficient. We need a new secure protocol which uses cryptography. This protocol was called Secure Sockets Layer a.k.a SSL. The combination of HTTP and SSL is called HTTPS.
This will address the two problems of the insecure HTTP:

Encrypting Insecure Data

Encryption is a mathematical transformation that is applied on a data, to yield a different data which is indecipherable. To achieve this, another string data is applied in the mathematical transformation and this string data is called encryption key.
Decryption is a mathematical transformation that is applied on indecipherable encrypted data, to yield the original data. To achieve this, a string data is also applied in the mathematical transformation and this string data is called decryption key.
This is shown below:

The encryption and decryption may be the same, in which case this is called symmetric cryptography. In SSL, we use something called as asymmetric cryptography which is a.k.a. public key encryption. We use public key encryption because, the encryption key can be shared with all the users, whereas the decryption is private and only server knows it. In this way, we can avoid sharing the key to everyone, thereby only server knows how to decrypt the data.

Trusting Server Identity

The client knows whether the server is whom they expect via the SSL handshake process. When the client makes a TCP connection to the server, the SSL handshake process starts.
During the SSL handshake process, the server sends the client a signed SSL certificate indicating that it is the authentic server. This signed SSL certificate certifies that the server is trustworthy. The signed SSL certificate has to be installed in the server. The company owning the server needs to contact an organization called certificate authority to obtain this.
This process is shown below :

Before creating the certificate, the CA verifies the identity of the company. Only after that it provides a signed certificate. This certificate has to be installed on the server by the company. Once the certificate is installed in the server, the handshake can happen with client. The handshake process is depicted below:

Summary of handshake:

• The client sends the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.
• The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate.
• The client uses the information sent by the server to authenticate the server—e.g., in the case of a web browser connecting to a web server, the browser checks whether the received certificate's subject name actually matches the name of the server being contacted, whether the issuer of the certificate is a trusted certificate authority, whether the certificate has expired, and, ideally, whether the certificate has been revoked. If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to the next step.
• Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher in use) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.
• If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.
• If the server has requested client authentication, the server attempts to authenticate the client. If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
• Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
• The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.
• The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.