HTTPS Introduction

HTTPS (HTTP over SSL) was introduced to address the security vulnerabilities of HTTP, such as eavesdropping and identity spoofing. It uses SSL or TLS to encrypt communication between the client and the server.

Problems with HTTP

• Communication uses plain text, making it susceptible to eavesdropping.
• Unable to verify the identity of the communication party, making it vulnerable to spoofing (e.g., Denial of Service attacks).
• Cannot guarantee message integrity, making it possible for messages to be altered (e.g., Man-in-the-Middle attacks).

To address these issues, we need:

• Encryption to prevent eavesdropping.
  • Encrypting either the content or the communication channel can help secure the communication.
• Authentication to prevent impersonation attacks.
  • Certificates are commonly used for identity verification.
• Integrity checks to prevent tampering.
  • Hash functions like MD5 and SHA-1 are often used to ensure data integrity.

HTTPS

To solve the above problems comprehensively, we add encryption, authentication, and integrity protection to HTTP, resulting in HTTPS.

$HTTP + Encryption + Authentication + Integrity Protection = HTTPS$

HTTPS over SSL

HTTPS is not a new protocol; it simply adds SSL or TLS between HTTP and TCP. By doing so, HTTPS provides encryption, certificates, and integrity protection.

SSL is independent of HTTP, and it can be used with other protocols like SMTP and Telnet to provide encryption.

Encryption Mechanism

HTTPS uses both symmetric (shared key) and asymmetric (public key) encryption to achieve its goals effectively:

• Public key encryption is used to encrypt the shared key (Pre-master secret), ensuring it cannot be intercepted.
• Once the shared key is established, symmetric encryption is used for communication to ensure better performance.

Key differences:

• Public key encryption: Asymmetric, secure but computationally expensive.
• Shared key encryption: Symmetric, less secure for key exchange but more efficient for encryption.

Authentication Mechanism

Public key encryption requires proof that the public key itself is legitimate and not replaced. HTTPS uses certificates to achieve this authentication.

Certificates are issued by Certificate Authorities (CAs), who verify the identity of the party requesting the certificate and sign the public key.

• The server sends the signed public key certificate to the client using public key encryption.
• The client uses the CA’s public key to verify the signature. If verified, it proves:
  • The CA is trustworthy.
  • The server’s public key is legitimate.
• Both parties then use the public key to establish a secure channel.

The CA’s public key is usually pre-installed in browsers.

Integrity Protection

HTTPS ensures message integrity by using message digest algorithms.

Hash Algorithms

These algorithms, also known as hash or digest functions, convert input data of any length into a fixed-length output string, such as MD5 and SHA-2.

A hash algorithm is not an encryption algorithm. It cannot be reversed to obtain the original data, so it can only be used for integrity checking.

Applications attach a Message Authentication Code (MAC) to messages. The MAC helps detect tampering, thus ensuring the integrity of the communication.

HTTPS Communication Flow

Other Considerations

• Due to the overhead of encryption, decryption, and SSL handshake, HTTPS is generally slower and requires more CPU resources than HTTP.
  • SSL accelerators (dedicated servers) are sometimes used to mitigate this issue.
• When a client repeatedly accesses the same HTTPS server, it may not need to perform a complete TLS handshake each time.
  • The server maintains a session ID for each client and uses it to resume secure sessions, avoiding a full handshake.

References

• MDN Web Docs
• Wikipedia
• Cxuan’s Blog
• “Illustrated HTTP/HTTPS”