How HTTPS or SSL/TLS works

  1. After browser send a request, at first Server sends its public key to the browser .
  2. Browser generate Random Session key and encrypt this key using received public key of server.
  3. Browser sends this encrypted session key to server and server decrypt that received key using his ownprivate key.
  4. Now both have session keys which can be used to encrypt and decrypt messages.
  1. First of all, the user creates a public key and private key for his website (suppose a website ‘www.abc.com’). Then he sends his public key along with other personal information such as his driving license to a Certificate authority (CA). CA first verifies whether this site belongs to him or not, if verified then CA signs these details using his own private key( i.e CA private key) and sends this back to the user. In the webserver user store that certificate. [Note there are several CA such as lets encrypt, open ssl, godaddy. Infact this CA again trusted another CA. So overall there is a chain of CA and at the end there is Root CA. Also instead of using this CA, you can create own CA and generate certificate know as self signed certificate, but by default browser does not trust your CA, so you have to manually install your CA cert in browser locally.]
  2. Now at the time of communication, web surfing following steps occurs
  3. First user click website eg: ‘www.abc.com’ in the web browser which will initially send a hello request to the server
  4. Server get this request and before sending any data to client,he sends his certificate to the browser
  5. Browser receives a certificate and at first, it checks whether the issuer of this certificate which is CA is trusted or not. This is done by, browser already have a list of trusted CA in his setting, if it does not found, its mean browser doesn’t trust that CA and show error
  6. Now if the browser trusts that CA, it checks the validity of that certificate to check whether the certificate is tempered or not by a hacker. This is done by, browser already has the public key of that CA, and it uses that key to verify the validity of the certificate. Also, other info such as expiry date of the certificate is verified.
  7. If it is valid, it is sure that the public key is valid and sends from genuine website ie ‘www.abc.com’, and upcoming steps after this steps, we already described above, ie browser generate a session key, encrypt that session key using the public key of server which is received in the certificate, then send this encrypted that key to the server, server decrypt that using his private key, now both have sam session key, ie now communication established, first send a response of ‘www.abc.com’ to the browser in encrypted form and proceed other communication. This session key is valid for a session such as until the browser close, or up to a certain time. Till this session, same key is used for encryption, decryption, but after the ending of the session, if the user again requests site then this process of sending certificate by the server, validation in the browser, encryption is repeated again.
HTTPS flow

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store