Category
Internet – Blog No 2
Time to Read
30 Minutes
Who should read this blog?
To learn about HTTPS , SSL/TLS.

Preface

God! I adore this character. A guardian angel, watching over Gotham City when no one expects. You can not see him but he is there protecting lives and the city. You don’t see him, but he is everywhere doing his job in darkness. There is one more like him. It looks like a “Lock” symbol on your browser, you don’t even realize he is working stealthily 24*7 protecting you and your identity on the Dark Night out there.

He is our savior – The HTTPS Protocol.

---

HTTPS Protocol

HTTPS protocol is a combination of HTTP protocol and SSL/TLS protocol. So in reality it is the SSL/TLS part of the protocol which provides the security.

Here are some common areas where TLS/SSL protocol is used:

Apart from HTTPS, SSL/TLS protocol use cases are in emails, VPN, VOIP, instant messaging, Secure FTP, RDP, and IOT.

SSL and TLS are used interchangeably but they are different and the major difference is that SSL is proprietary to Netscape, while TLS is an open standard protocol. Both have many versions but it is always advised to use the latest version for the best security.

---

HTTP and how does it work?

Before understanding how HTTPS works – it is necessary to understand how HTTP works.

When a client opens a webpage https://thecloudblogger.com in his web browser, first DNS resolution happens for the webpage, after DNS resolution is successful, the client knows the IP address of the web server where the website is hosted, then the client tries to form a 3-way TCP handshake with the DNS-resolved IP address.

As soon as the TCP session is completed – which takes 2 round-trip times, an HTTP GET request is generated by the user browser which contains the information about the HTTP version (1.0,1.1, or 1.2), website hostname(thecloudblogger.com) and authorization ( which contains user and password details for page login ). Once the server received this GET request, the server responds with an HTTP Response 200 ok, which means the server has accepted the client request and sends the requested webpage in the HTTP response body.

The Internet is an unprotected environment and since the HTTP protocol does not use any security measures, it is vulnerable to hacking where a hacker can capture the traffic and know your session details. It could be disastrous in case if you are logging into your bank website and someone learns the username and password and other session details. However, no bank website uses HTTP, but the objective is to list the downsides of the HTTP protocol.

---

HTTPS protocol

In the previous section, we saw how the HTTP protocol was an unsecured communication and how there was a need emerged to use a secure channel over the internet which is an unsecured open channel. with this requirement, HTTPS protocol came to the fore.

HTTPS protocols operate on CIA which is a basic construct of the security mechanism.

C represents confidentiality, I represents Integrity and A represents Availability.

As we know confidentiality makes sure that the original data is not leaked during its transfer as it is encrypted while being transferred over the Internet.

Integrity makes sure that the data should not be altered during its transfer, and even if does, the receiver knows that the data is changed.

Availability refers to the accessibility of information whenever it is needed. In the context of HTTPS, availability is not directly related to the protocol itself, but rather to the overall security measures implemented by the website and its hosting infrastructure. HTTPS helps protect against certain types of cyber attacks, but it doesn’t guarantee availability on its own. Websites need to implement additional measures, such as robust server infrastructure and protection against Distributed Denial of Service (DDoS) attacks, to ensure availability.

---

HTTPS Negotiation

In this HTTPS Negotiation process, SSL/TLS handshake negotiation happens just after the TCP 3-way handshake session is established between client and server and before the actual HTTP data transfer takes place.

Purpose of TLS Negotiation

The purpose of HTTPS negotiation is to use certificates/cryptography to establish a secured channel over unsecure internet to transfer the website traffic securely.

SSL/TLS handshake fulfills the below objectives –

• Cipher suite and its parameters exchange
• Authentication
• Create and Exchange session keys (Symmetric keys )
• Change Cipher Spec.
• Application Data Exchange

Note

Encryption can be performed in two ways – Symmetric key encryption and Asymmetric key encryption.In SSL/TLS negotiation Asymmetric key negotiation is performed first with help of certificate to generate a session key(symmetric key). Symmetric key is then used to encrypt actual website traffic. Why ?, becuase Asymmetric key computation is very secure but compuation wise very heavy CPU intesive as they use different keys for encryption and decryption.

---

Cipher suite Negotiation

The client can use different browser software, like, Chrome, Edge, Mozilla, etc. to access the internet, similarly, the servers can use different web servers like IIS, Nginx, and Apache for hosting the website. Since they are different platforms from different vendors and could have a lot of supported features, it becomes important that they negotiate Confidentiality parameters( key exchange protocol, Encryption protocol) and Integrity parameters (MAC and HASH algorithms) in advance so that a smooth SSL/TLS handshake could be achieved.

Cipher suites are suggested by the client browser as what all cipher suites it can support to the server during the client hello message, this message is transferred just after the TCP session is established.

Client hello also includes the details of TLS versions supported like TLS ( V 1.0,1.1,1.2,1.3) and a random client number generated. Refer to the packet capture –

The server side goes through the supported Cipher suites and picks up a Cipher suite, the selected cipher suite is then used during the TLS Negotiation. Server-side also presents its certificate and a random server number generated.

Client and server hello are described as below –

Here’s an example of a cipher suite selected by our server :

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

In this example, the cipher suite consists of the following components:

Key Exchange Algorithms:

This component determines how the Asymmetric encryption keys are used between the client and the server. Common key exchange algorithms include:

• RSA (Rivest-Shamir-Adleman): The RSA algorithm is a widely used asymmetric encryption algorithm for key exchange. It relies on the use of public and private key pairs.
• Diffie-Hellman (DH): The Diffie-Hellman algorithm enables secure key exchange over an insecure channel. It allows the client and server to independently generate a shared secret key without revealing it during transmission.
• Elliptic Curve Diffie-Hellman (ECDH): ECDH is a variant of the Diffie-Hellman algorithm that uses elliptic curve cryptography for key exchange. It provides similar functionality but with smaller key sizes.

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is being used in this case.

Encryption Algorithm:

This component determines the algorithm used to encrypt the data being transmitted using a symmetric key. Common encryption algorithms include:

• Advanced Encryption Standard (AES): AES is a widely used symmetric encryption algorithm. It supports different key sizes, such as AES-128, AES-192, and AES-256, indicating the length of the encryption key in bits.
• Triple Data Encryption Standard (3DES): 3DES is a symmetric encryption algorithm that applies the Data Encryption Standard (DES) algorithm three times in succession for enhanced security.

AES_256_GCM (Advanced Encryption Standard 256-bit in Galois/Counter Mode) is being used in this case.

AES with a key size of 256 bits is used for symmetric encryption of the data.
GCM is a mode of operation that provides authenticated encryption and integrity checks.

Message Authentication Code (MAC) Algorithm:

SHA-384 is used for generating a unique code, known as the MAC, to ensure the integrity of the data so that we can find if data was changed in transit over unsecured internet.

---

Authentication

This requires a separate session in itself and I promise I will bring it shortly.

For starters just think of the complexity – On the huge internet, which is ever-changing and expanding we need a system that can keep track of the genuine websites owned by the organizations are indeed owned by them. Because When a user opens a bank website – that Lock symbol represents the trust that the website is indeed a bank website and on that trust, he is ready to enter his credentials on that website.

Authentication is a two-way road, the website is authenticated by the client browser by validating the certificate chain shared by the server during the server hello message. Once the website is authenticated by the browser you see the Lock sign otherwise if the certificate is not recognized by the browser you see this page- Beware

Client-side is authenticated mostly by requesting the user credentials which are then matched against the saved user profile on the server. In rare scenarios, certificate-based authentication is used on the client side.

• If the server’s digital certificate is required for client authentication or verifying the server’s identity, it is sent as part of the handshake in the server hello message.
• The client verifies the server’s certificate using a trusted set of Certificate Authorities (CAs). This involves checking the certificate’s validity, verifying the digital signature, and ensuring it matches the server’s identity.

---

Create and Exchange sessions (symmetric) keys

Once the server is authenticated by the client side with the help of a certificate. We are ready to transfer the website data. But we would need to have a symmetric session key so that we can use the same symmetric keys to encrypt the data on the client side and decrypt the same data on the server side using the same key.

This means once we create the symmetric key on the client side, we need to transfer the same key to the server side in a way that is a highly protected channel created by Asymmetric key encryptions like RSA or Diffie Hillman.

Asymmetric keys consist of public/private key pair, which are different but complement each other in the encryption and decryption process. Just think of a lock that if locked by a public key, can be unlocked only by a private key and vice versa. This is how the process goes –

• The client generates a pre-master secret, encrypts it with the server’s public key (from the certificate), and sends it to the server.
• The server decrypts the pre-master secret using its private key, obtaining the shared secret.
• Both client and server independently derive the session keys (encryption and integrity protection keys) from the shared secret and the random values exchanged earlier during the client and server hello exchange.
• Once encryption and integrity protection keys are generated they are used to encrypt and hash the data using the algorithm shared during cipher suiter negotiation AES_256_GCM and hashing algorithm SHA384.

---

Change Cipher Spec

• Since both the client and server have symmetric encryption and integrity keys available
• Both client and server inform each other that subsequent messages will be encrypted and authenticated using the negotiated parameters.
• This is accomplished by sending Change Cipher Spec messages, which essentially marked the transition to secure communication.
• Each change in Cipher Spec is recorded as the Finished message by both sides.

Application data Exchange

• Once the handshake is complete, both client and server can exchange application data securely using the agreed-upon encryption and integrity protection mechanisms.
• HTTPS requests and responses, including the HTML content, images, scripts, and other resources, are exchanged over the established secure connection.

This is what the entire process looks like –

As seen the full TLS negotiation takes 2 round trips but in optimized deployments, it can be reduced to 1 round trip time.