HTTPS and TLS Architecture: Cryptography, Handshakes, and PKI

Every secure interaction on the modern web—from online banking and e-commerce transactions to basic API queries—relies on Hypertext Transfer Protocol Secure (HTTPS) [1]. Plain HTTP transmits data in cleartext across the network, leaving credentials, session cookies, and personal data exposed to packet sniffing, adversary-in-the-middle interception, and content injection [1, 3].

HTTPS is not a separate application protocol; it is standard HTTP layered over an encrypted cryptographic transport layer: Transport Layer Security (TLS) [1]. In this technical analysis, we dissect the cryptographic architecture of TLS, contrast asymmetric versus symmetric encryption, examine the 1-RTT handshake in TLS 1.3, evaluate X.509 Public Key Infrastructure (PKI), and review HTTP Strict Transport Security (HSTS) [1, 2, 3].

1. Hybrid Cryptography: Why Both Asymmetric and Symmetric Ciphers Are Used

TLS achieves both strong security and high computational efficiency by combining two distinct branches of cryptography [1]:

1. Asymmetric Cryptography (Public-Key)

• Uses a mathematically linked pair: a public key (shared freely) and a private key (kept strictly confidential) [1].
• Algorithms: RSA, Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), or Ed25519.
• Characteristics: Highly secure for identity authentication and secret key exchange, but computationally slow and CPU-intensive [1, 3].

2. Symmetric Cryptography (Shared Secret)

• Uses an identical secret key for both encryption and decryption [1].
• Algorithms: AES-256-GCM, ChaCha20-Poly1305.
• Characteristics: Extremely fast. Modern CPU architectures (such as Intel/AMD with AES-NI instructions) encrypt and decrypt symmetric data streams at line rate (gigabytes per second) with negligible processor overhead [1].

The Hybrid Solution

TLS uses asymmetric cryptography during the initial handshake to authenticate the server and securely negotiate a shared session key. Once established, both parties switch exclusively to symmetric encryption to protect all subsequent application data [1, 3].

2. The TLS 1.3 Handshake: Speed and Forward Secrecy

Standardized in RFC 8446, TLS 1.3 completely overhauled previous versions (TLS 1.0, 1.1, and 1.2), eliminating obsolete cryptographic ciphers (RC4, 3DES, static RSA key exchange) and reducing handshake latency from 2 Round Trips down to a single Round Trip (1-RTT) [1]:

Client                                                   Server

ClientHello
  + Key Share (ECDHE)
  + Supported Ciphers      -------- 1-RTT -------->
                                                    ServerHello
                                                      + Key Share (ECDHE)
                                                      + Encrypted Certificate
                                                      + Finished Message
                           <-----------------------
[Both Compute Shared Secret]
[Session Keys Generated]

HTTP GET (Encrypted)       ----------------------->
                           <----------------------- HTTP 200 OK (Encrypted)

Perfect Forward Secrecy (PFS)

In TLS 1.3, static RSA key exchange is completely prohibited [1]. The handshake mandates ephemeral Diffie-Hellman key exchange (ECDHE) [1]:

• For every new session, client and server generate temporary, single-use key shares.
• Even if an adversary records encrypted network traffic for years and subsequently steals the server's long-term private SSL key, they cannot retroactively decrypt past recorded sessions [1, 3].

3. Public Key Infrastructure (PKI) and X.509 Certificates

How does a browser know that an encryption key truly belongs to deprogit.com rather than an impostor? This is governed by the X.509 Public Key Infrastructure [1, 3]:

1. Certificate Authorities (CAs): Trusted third-party entities (such as Let's Encrypt, DigiCert, Sectigo) whose root certificates are pre-installed in client operating systems and browsers [3].
2. Chain of Trust: The server presents its digital certificate, which is cryptographically signed by an intermediate CA, which in turn is signed by a trusted root CA.
3. Verification: The client verifies the digital signatures down the chain using the CAs' known public keys. If the domain matches and the signature chain is mathematically valid, the connection is trusted [1, 3].

4. HTTP Strict Transport Security (HSTS - RFC 6797)

Even with TLS configured, a vulnerability exists: when a user types deprogit.com into their address bar, browsers initially attempt an unencrypted HTTP connection before being redirected to HTTPS via a 301/302 response [2]:

• During that unencrypted redirect, an attacker on a public Wi-Fi network can execute an SSL stripping attack, intercepting traffic before encryption takes effect [2].

Enforcing HSTS

Domain owners eliminate this vulnerability by publishing the HSTS HTTP response header [2]:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• Instructs the browser to never attempt unencrypted HTTP connections to the domain for the specified duration (e.g., 2 years) [2].
• Submitting the domain to the official HSTS Preload List embeds this requirement directly into browser source code, ensuring even the very first connection is made strictly over HTTPS [2].

TLS Protocol Version Comparison

Practical Server Hardening Steps

To ensure enterprise-grade HTTPS security:

1. Disable Legacy Protocols: Disable TLS 1.0 and TLS 1.1 globally on web servers and load balancers; support only TLS 1.2 and TLS 1.3 [1, 3].
2. Automate Certificate Lifecycle: Deploy automated ACME protocol clients (such as Certbot) to renew TLS certificates automatically every 60 days, preventing catastrophic service outages caused by expired certificates [1].
3. Deploy HSTS with Subdomains: Enable HSTS across all corporate web properties to prevent SSL stripping attacks [2].

For enterprise web platform security, automated TLS deployment, and web application architecture, explore our offerings on our Web & Software Development page.

Key Takeaways

• HTTPS encapsulates standard HTTP traffic inside an encrypted TLS cryptographic tunnel.
• TLS combines asymmetric cryptography for initial key exchange with high-speed symmetric encryption for application data.
• TLS 1.3 reduces handshake time to 1-RTT and mandates Perfect Forward Secrecy (PFS) via ephemeral Diffie-Hellman.
• HSTS response headers instruct browsers to enforce HTTPS strictly, preventing SSL stripping attacks on public networks.

Need help with this? Contact us.

Sources

[1] IETF, "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3", 2018. URL: https://www.rfc-editor.org/rfc/rfc8446.html (Authoritative standards specification defining TLS 1.3, 1-RTT handshakes, forward secrecy, and cipher requirements).

[2] IETF, "RFC 6797: HTTP Strict Transport Security (HSTS)", 2012. URL: https://www.rfc-editor.org/rfc/rfc6797.html (Standards-track specification for declaring strict HTTPS transport security policies in web user agents).

[3] National Institute of Standards and Technology (NIST), "NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations", 2019. URL: https://csrc.nist.gov/pubs/sp/800/52/r2/final (Federal technical standard governing TLS configuration, cipher suites, and certificate validation).

Last reviewed: October 2026