Understanding HTTPS: TLS/SSL Principles, Encryption, Digital Signatures, and Certificate Authorities

1. Basic Concepts and Understanding

HTTPS adds a security layer between HTTP and TCP, encrypting data before it reaches TCP. The security relies on three core algorithms: hash functions, symmetric encryption, and asymmetric encryption. Asymmetric encryption provides authentication and key exchange, while symmetric encryption uses the negotiated key to protect data, and hash functions verify integrity.

TLS/SSL Functionality

TLS/SSL depends on hash functions, symmetric encryption, and asymmetric encryption. Asymmetric encryption authenticates identities and negotiates keys; symmetric encryption encrypts the actual payload; hash functions ensure data integrity.

Difference Between SSL and TLS

SSL is the predecessor of TLS. SSL 2.0 was released in 1995, quickly replaced by SSL 3.0 in 1996. TLS 1.0 was built on SSL 3.0 in 1999. Modern servers should disable SSL 2.0/3.0 and use TLS, with TLS 1.2 being the mainstream version.

SSL/TLS and Certificates

Certificates are issued by third‑party Certificate Authorities (CAs). The certificate itself does not depend on the protocol; you can use a certificate with any TLS version, and the server configuration determines which protocol is used.

Key Types

Symmetric key: a single secret used for both encryption and decryption.

Public key and private key: a pair where the public key is shared openly and the private key is kept secret.

Example: Party A has a public/private key pair (A_pub, A_priv); Party B has (B_pub, B_priv). A encrypts data with B_pub and signs with A_priv; B decrypts with B_priv and verifies with A_pub.

Symmetric Encryption

Uses the same key for encryption and decryption. The key must be securely transmitted to the other party, which is why asymmetric encryption is used to protect the key exchange.

Why Use Asymmetric Encryption

Transmitting a symmetric key in plain text is vulnerable to interception. Asymmetric encryption allows the key to be encrypted with the recipient’s public key, ensuring only the holder of the corresponding private key can decrypt it.

Asymmetric Encryption Algorithms

Common algorithms include RSA, ECC, and DH. The sender encrypts data (or a symmetric key) with the recipient’s public key; the recipient decrypts with their private key.

Advantages and Disadvantages of Asymmetric Encryption

Provides authentication and secure key exchange.

Public keys can be freely distributed.

Enables one‑to‑many secure communication.

Higher computational cost than symmetric encryption.

Potential for man‑in‑the‑middle attacks if the public key is tampered.

Public key alone cannot encrypt data without the corresponding private key for decryption.

Hybrid Encryption in HTTPS

HTTPS combines asymmetric encryption for the key exchange and symmetric encryption for the data transfer. The client generates a random symmetric key, encrypts it with the server’s public key, and sends it to the server. Subsequent communication uses the symmetric key for efficiency.

2. Certificate Authority (CA) and Third‑Party Certification

Third‑party certification (e.g., CA, CE, QA/QC) validates the legitimacy of an organization or product. A CA issues digital certificates that bind a public key to an entity’s identity.

Digital Signature Generation

Plain text → Hash function → Message digest → Private key encryption → Digital signature

The sender signs the hash of the message with their private key. The receiver verifies the signature by decrypting with the sender’s public key and comparing the resulting digest with a freshly computed hash of the received message.

Certificate Authority Workflow

Server operator submits public key and organization details to a CA.

CA validates the information (existence, legality, domain ownership).

Upon approval, CA issues a certificate containing the public key, organization info, CA info, validity period, and a CA signature (hash of the certificate data encrypted with the CA’s private key).

During an HTTPS handshake, the server presents this certificate to the client.

The client verifies the certificate by checking the CA’s signature (using the trusted CA public key) and validates the certificate’s fields (domain, expiration, etc.).

Digital Signature Role

Authenticates the sender’s identity.

Ensures message integrity (detects tampering).

3. HTTPS Handshake (TLS 1.2) Process

Client initiates an HTTPS request to port 443, requesting the server’s public key.

Server returns its digital certificate (containing the public key).

Client validates the certificate using built‑in trusted CA public keys and verifies the signature.

Client generates a random symmetric key, encrypts it with the server’s public key, and sends it to the server.

Server decrypts the symmetric key with its private key; both parties now share the same symmetric key.

Subsequent data exchange is encrypted/decrypted with this symmetric key.

When Asymmetric vs. Symmetric Encryption Is Used

Asymmetric encryption is used only during the key‑exchange phase; after the symmetric key is established, all traffic uses symmetric encryption.

4. HTTP vs. HTTPS

HTTP transmits data in clear text; HTTPS adds SSL/TLS encryption and authentication.

HTTPS improves security, SEO ranking, and displays a green lock in browsers.

HTTPS requires an SSL/TLS certificate; HTTP does not.

Standard ports: HTTPS 443, HTTP 80.

HTTPS operates at the transport layer; HTTP at the application layer.

5. Why Not All Websites Use HTTPS

Perceived deployment overhead (obtaining and configuring a CA‑issued certificate).

Concern about performance impact, though optimizations and CDN/SLB can mitigate this.

Cost of purchasing certificates.

Varying security awareness across regions and organizations.

6. Summary

HTTPS secures communication by using SSL/TLS protocols: the client obtains the server’s public key, generates a symmetric key, encrypts it with the public key, and then both sides exchange data using the symmetric key. Certificate Authorities provide trusted digital certificates and signatures, ensuring the public key belongs to the legitimate server and protecting against man‑in‑the‑middle attacks.