Deep dive into HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is a secure extension of the standard Hypertext Transfer Protocol (HTTP) used for communication over the internet. HTTPS ensures that the data transmitted between a user’s browser and a website’s server is encrypted and secure, protecting sensitive information from being intercepted or tampered with by malicious actors.

Key Features of HTTPS:

Encryption: HTTPS employs encryption mechanisms to encode the data being exchanged. This prevents unauthorised parties from reading the information while it’s in transit.

Authentication: HTTPS verifies the identity of the website using digital certificates. These certificates are issued by trusted Certificate Authorities (CAs) and help users establish the legitimacy of the website they are visiting.

Data Integrity: HTTPS guarantees the integrity of the data transferred between the client and the server. Any modifications to the data during transmission are detected and rejected.

Trustworthiness: Users can trust that the data they’re sharing, such as personal information and payment details, is protected and not accessible to malicious entities.

How HTTPS Works:

HTTPS relies on the use of cryptographic protocols such as Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL), to establish a secure communication channel.

The process involves:

Handshake: The client (browser) initiates a connection request to the server. The server responds with its digital certificate, containing its public key.

Certificate Verification: The client verifies the certificate’s authenticity and validity using a chain of trust rooted in trusted Certificate Authorities.

Key Exchange: The client and server use a secure key exchange mechanism, such as Diffie-Hellman, to establish a shared secret key for encrypting and decrypting data.

Data Transfer: Data exchanged between the client and server is encrypted using the established shared secret key (Symmetric key).

Session Key Renewal: Periodically, new session keys are generated to enhance security.

Benefits of HTTPS:

Security: HTTPS prevents eavesdropping, data theft, and unauthorised access to sensitive information.

SEO Benefits: Major search engines give preference to HTTPS-enabled websites in search rankings.

User Trust: HTTPS signals a commitment to security, building trust among users.

Compliance: Many regulations and standards (e.g., GDPR) require the secure transmission of personal and sensitive data.

E-Commerce: For online businesses, HTTPS is essential for secure payment transactions.

In summary, HTTPS has become a cornerstone of secure online communication, safeguarding user data and ensuring the confidentiality, integrity, and authenticity of information exchanged between users and websites.

TLS Handshake: Establishing Secure Connections (TLS 1.2)

The Transport Layer Security (TLS) handshake is a critical process that occurs at the beginning of a secure communication session between a client (e.g., a web browser) and a server. It establishes the foundation for secure data exchange by ensuring confidentiality, data integrity, and authentication.

Key Steps in the TLS Handshake:

ClientHello: The client initiates the handshake by sending a ClientHello message to the server. This message includes:

The highest supported TLS version.

A random value generated by the client.

A list of cipher suites (encryption algorithms) supported by the client.

Other relevant parameters.

ServerHello: The server responds with a ServerHello message, selecting the highest supported TLS version from the client’s list and choosing a cipher suite from both the client’s and server’s lists. The ServerHello message includes:

The chosen TLS version.

A random value generated by the server.

The selected cipher suite.

Other relevant parameters.

Server Certificate: If the selected cipher suite involves asymmetric cryptography (like RSA or ECDSA), the server sends its digital certificate to the client. This certificate contains the server’s public key and is used for authentication.

Key Exchange: If the chosen cipher suite uses asymmetric cryptography or Diffie-Hellman key exchange, this step occurs. The client and server establish a shared secret key (session key) using their private keys, public keys, or DH parameters. The shared secret key will be used for encrypting and decrypting data during the session.

Client Key Exchange and Finished: The client sends a message to the server that contains information to help establish the session key and also includes a hash of all the messages exchanged so far, ensuring data integrity.

Server Finished: The server responds with its own hash of the exchanged messages, further confirming data integrity.

Outcome:

At the end of the TLS handshake, both the client and the server possess the shared session key. Subsequent communication between them is encrypted and secure using this key. The handshake ensures that the connection is authenticated, the data exchanged is encrypted, and any tampering is detected.

Diffie-Hellman Key Exchange

The Diffie-Hellman (DH) key exchange is a fundamental cryptographic protocol that enables two parties to securely exchange cryptographic keys over an insecure channel. Named after its inventors Whitfield Diffie and Martin Hellman, this protocol forms the basis for secure key exchange and helps establish private communication channels in scenarios where the parties have no prior shared secret.

Key Concepts of Diffie-Hellman:

Public and Private Keys:

Each party generates a private key, kept secret, and a public key, shared with the other party.

The public keys can be openly transmitted, but the private keys must remain secret.

Modular Arithmetic:

The key exchange is based on modular arithmetic performed in a finite field, often using a prime modulus and a primitive root.

The security relies on the difficulty of solving the discrete logarithm problem.

Key Calculation:

Both parties combine their own private key with the other party’s public key to compute a shared secret key.

Despite having different private keys, the shared secret key is the same for both parties.

Security:

The strength of the Diffie-Hellman protocol lies in the complexity of calculating the private key from the public key, which is computationally infeasible for large prime numbers.

How Diffie-Hellman Works:

Here’s a simplified numerical example of the Diffie-Hellman key exchange:

Setup:

Let us choose prime modulus ‘p’ as 23 and primitive root ‘g’ as 5.

Client (Alice) and Server (Bob) Private Keys:

Alice chooses her private key ‘a’ as 6.

Bob chooses his private key ‘b’ as 15.

Calculating Public Keys:

Alice calculates her public key ‘A’ as A = g^a mod p = 5⁶ mod 23 = 8.

Bob calculates his public key ‘B’ as B = g^b mod p = 5¹⁵ mod 23 = 19.

Exchange of Public Keys:

Alice sends her public key ‘A’ to Bob.

Bob sends his public key ‘B’ to Alice.

Shared Secret Calculation:

Alice calculates the shared secret key ‘s’ using Bob’s public key ‘B’:

s = B^a mod p = 19⁶ mod 23 = 2.

Bob calculates the shared secret key ‘s’ using Alice’s public key ‘A’:

s = A^b mod p = 8¹⁵ mod 23 = 2.

Session Key Derivation:

Both Alice and Bob have now derived the same shared secret ‘s’, which can be used to derive session keys for encryption and decryption.

In this example, the exchanged public keys ‘A’ and ‘B’ are exchanged in plaintext and do not compromise the security of the key exchange. An eavesdropper would have difficulty deducing the shared secret ‘s’ from the exchanged public keys, as it involves solving the discrete logarithm problem, which is computationally challenging for large prime numbers.

Keep in mind that real-world implementations use much larger prime numbers and more complex cryptographic algorithms to ensure security.