Skip to content

HTTPS

  • HTTPS = HTTP + TLS

  • Encryption: data is scrambled so outsiders can't read it.

  • Integrity: ensures data isn't tampered with in transit. (e.g., man in the middle attack)
  • Authentication: verifies the server (and sometimes the client) is who they claim to be.

Workflow

  1. TCP Handshake

  2. Before TLS starts, the browser and server establish a TCP connection (the classic 3-way handshake).

    • Client → SYN
    • Server → SYN-ACK
    • Client → ACK
    • Now TCP is ready, and TLS can begin.

  3. ClientHello

    • Client (browser) → Server. The message contains the following:
    • Supported TLS versions (e.g. TLS 1.2, TLS 1.3) - for this case consider 1.3
    • Supported cipher suites (algorithms for key exchange, encryption, hashing) (e.g. TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256)
    • ECDHE key share (part of Diffie-Hellman key exchange for ephemeral keys) (e.g. X25519 or P-256)
    • Random number (used later in key generation)
    • Optional: Extensions (like Server Name Indication, to tell which domain if multiple run on the same IP)

  4. ServerHello

    • Server → Browser. The message contains the following:
    • The chosen TLS version (e.g., TLS 1.3)
    • The chosen cipher suite (must be one the client supports)
    • Its ECDHE key share (server's side of the Diffie-Hellman exchange). From the two key shares, both sides derive the first set of secrets. From this point on, most handshake messages are encrypted.
    • openssl s_client -tls1_3 -connect www.google.com:443 inspect a TLS1.3 handshake
    • In TLS 1.3 the server certificate is sent in a latter step! (TLS 1.2 only) The server's digital certificate (X.509) (signed by a trusted Certificate Authority), containing: Public key, Domain name, Issuer (CA), Signature from the CA. The server proves its identity via this certificate.

  5. Encrypted server handshake messages

    • Server -> Client (encrypted with handshake keys):
    • Certificate (X.509 chain proving server identity)
    • CertificateVerify (proof of private key ownership)
    • EncryptedExtensions (negotiated features)
    • Optionally CertificateRequest (if it wants client auth)

  6. Client verification and finish

  7. The client checks:
    • Is the cert issued by a trusted CA (in root store)? (verified with a public key pre-installed in the OS)
    • Is the cert valid (date, revocation)?
    • Does the cert domain match the URL?
  8. If not → Browser shows "Your connection is not private".

  9. echo | openssl s_client -connect www.google.com:443 2>/dev/null | openssl x509 -noout -text to parse the certificate

  10. Application data

    • Both sides derive application traffic keys and switch to them
    • All HTTP data is now encrypted with symmetric crypto (e.g. AES-GCM or ChaCha20-Poly1305).

Types of keys used in the process

  • Asymmetric
  • Server certificate key (RSA or ECDSA) to authenticate the server

  • The ECDHE key exchange uses ephemeral asymmetric keys to agree on a shared secret

  • Symmetric:

  • Derived session keys (AEAD ciphers) encrypt integrity-protected HTTP traffic
  • Symmetric keys are fast and used for all bulk data.
  • Asymmetric keys (e.g., RSA) are not used to encrypt the data itself because it's slower

Cipher Suite

  • Set of protocols to be used in the communication
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • ECDHE: Elliptic Curve Diffie Hellman Exchange
  • ECDSA: Elliptic Curve Digital Signature Algorithm

Deliverying key for encryption

Without Diffie Hellman

  • the TLS key is generated by the client
  • The TLS key is encrypted with the server public key

  • The TLS key encrypted is sent to the server

  • Drawbacks!

  • The same rsa key pair of the server is used both for authentication and data encryption
  • RSA pair should be used only for authentication! Not for descryption

With Diffie Hellman

  • The public key of the server is NOT used for encryption

  • The key for encryption is negotiate using diffie hellman algorithm

  • This algorithm generate keys over insecure public connection

  • Nevertherless only they know the keys generated!
  • Use one way function
    • Modulus: (g^a mod p)^b mod p = g^ab mod p // (g^b mod p)^a mod p = g^ba mod p
    • Elliptic curve (ECDHE): y^2 = x^3 + ax + b // m(nG) = n(mG)