Monday, 16 September 2019

How HTTPS/SSL/TLS works

How HTTPS/SSL/TLS works

Before we begin this blog I wanted to understand how public and private key works. We will just do a quick remainder here. A public & private key pair is created at the same time not like one created yesterday and one tomorrowJ. They are created as a mathematical key pair together and the magic is anything you encrypt with one of them can be decrypted with the other and vice versa.  Anything you encrypt with the private key can be decrypted with the public key. Anybody can create the key pair, we can create them either in the cisco router, on a server,. The secret of them is we can keep the private key private not sharing with anybody and you can share the public key with anybody you want to.

Digital Signature and  how it works

A Digital signature is a hash that has been encrypted with the sender’s private key.

The sender of a packet will take the data and they will create a hash and then will take the hash and encrypt with the private key. Now the sender will send the data and the digital signature (HASH encrypted with private key) to the recipient.
Digital Signature = HASH(DATA)
Sender  (DATA + Digital signature ) --> recipient

Now the recipient takes the data and they generate the own hash and they then take the digital signature which is encrypted hash and they decrypt with the senders public key .  If the result is the same this confirms the integrity between the sender and the recipient.

  • Recipient receives the data and digital signature
  • Hash the received data
  • Decrypts the encrypted hash with senders public key
  • Compare both the HASH value.
  • If it matches then it compares the data is not tampered or not modified


In order to verify a digital signature from anybody  what is need is the public key. In order to verify amazon.com we need the amazon.com public key digital signature. 
Step 1: the Client sends the HTTPS – TCP - SYN request to the Server

Step 2: The Server then sends back the TCP – SYN –ACK response to the Client

Step 3: The Client finally sends the TCP – ACK packet to the server. At this stage the initial SSL –TCP three way handshake gets completed. Below packet capture screenshot contains the TCP Client -Server packet details.
Step 4: The Client sends SSL Hello request to the Server, at this step the client is trying to have a SSL conversation with the server. The client also exchanges the cipher parameters (that includes RC4, SHA, HMAC) to the server (This is similar to the VPN IKE parameters exchanges that happens during the phase 1)

Step 5: The Server response back to the client saying Hello, also it shares the server Digital certificate ( the certificate contains the Valid period, server public Key which was digitally signed by the CA server example VeriSign, Go Daddy, Verizon). Finally the server Hello Done gets completed.

Step 6: Client finally sends the TCP ACK response to the server for the SSL session. You can find the  Step 4 – 6 packet details from the below screenshot.
Step 7: The client exchanges the session key ,and change cipher specification to the server. The session key will be encrypted using the server public key .

Step 8: The server sends the change cipher spec , and Encrypted message.

Step 9: The client starts encrypting the  packet to the server




No comments:

Post a Comment

iRule

  iRule: -- o iRule is a powerful and flexible feature within the BIG-IP local traffic management (LTM). o IRule is a powerful & flexibl...