HTTPS & TLS Handshake
IntermediateHTTPS = HTTP over TLS. TLS authenticates the server via certificates and establishes an encrypted session key using asymmetric cryptography — then switches to fast symmetric encryption for all data.
Overview
TLS (Transport Layer Security) provides three guarantees: confidentiality (data is encrypted), integrity (data cannot be tampered with), and authentication (the server is who it claims to be). The TLS handshake negotiates these using public-key cryptography. The client verifies the server's certificate (signed by a trusted Certificate Authority), and both sides use asymmetric crypto to exchange a shared secret, from which symmetric session keys are derived. All subsequent data is encrypted with fast symmetric ciphers (AES-GCM). TLS 1.3 (2018) simplified the handshake to 1 RTT and removed weak cipher suites. Certificates bind a public key to a domain name — a CA signs the certificate to prove ownership. Backend engineers must understand TLS for configuring Spring Boot HTTPS, mutual TLS (mTLS) for service-to-service auth in microservices, and debugging certificate errors.
TLS 1.3 Handshake
TLS 1.3 completes in 1 RTT (down from 2 in TLS 1.2). The client sends its key share (Diffie-Hellman public key) in the first message, enabling the server to derive the session key and immediately encrypt its response.
// TLS 1.3 Handshake (1 RTT):
//
// Client Server
// │ │
// │── ClientHello ─────────────────────────>│
// │ (TLS version, cipher suites, │
// │ client DH key share) │
// │ │
// │<── ServerHello ─────────────────────────│
// │ (chosen cipher, server DH key share, │
// │ Certificate, CertificateVerify, │
// │ Finished) ← all ENCRYPTED │
// │ │
// │── Finished ────────────────────────────>│
// │══════════════ Encrypted data ═══════════│
// Session key derivation (both sides independently compute same key):
// client_secret = DH(client_private, server_public)
// server_secret = DH(server_private, client_public)
// client_secret == server_secret (Diffie-Hellman property)
// Session key derived from this shared secret via HKDF
// TLS 1.2 vs TLS 1.3:
// TLS 1.2: 2 RTT, RSA key exchange (server decrypts with private key — no PFS)
// TLS 1.3: 1 RTT, DH key exchange only (Perfect Forward Secrecy always on)
// PFS = even if server private key is stolen later, past sessions cannot be decryptedCertificates, CAs & mTLS in Spring Boot
A certificate binds a public key to a domain. The Certificate Authority (CA) signs it. Browsers trust a built-in list of root CAs. Mutual TLS (mTLS) requires the client to also present a certificate — used for service-to-service authentication in microservices.
// Spring Boot — enable HTTPS:
// application.properties:
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password=changeit
server.ssl.key-store-type=PKCS12
server.ssl.key-alias=myapp
server.port=8443
// Generate self-signed cert for dev:
// keytool -genkeypair -alias myapp -keyalg RSA -keysize 2048
// -storetype PKCS12 -keystore keystore.p12 -validity 365
// Mutual TLS (mTLS) — client also presents certificate:
server.ssl.client-auth=need // require client cert
server.ssl.trust-store=classpath:truststore.p12
server.ssl.trust-store-password=changeit
// Certificate chain:
// Root CA (self-signed, in browser/OS trust store)
// └── Intermediate CA (signed by Root CA)
// └── Server Certificate (signed by Intermediate CA, for api.example.com)
// Browser verifies chain up to trusted Root CA
// Let's Encrypt — free automated CA:
// Issues 90-day certificates via ACME protocol
// Certbot auto-renews: certbot renew --pre-hook "stop nginx" --post-hook "start nginx"Key Points to Remember
- 1TLS provides confidentiality, integrity, and server authentication.
- 2TLS handshake: asymmetric crypto establishes shared secret → symmetric keys derived for data.
- 3TLS 1.3: 1 RTT handshake, DH-only key exchange, Perfect Forward Secrecy always enabled.
- 4Certificate binds public key to domain name, signed by a trusted Certificate Authority.
- 5mTLS requires both client and server to present certificates — used for microservice auth.
- 6Perfect Forward Secrecy: each session uses a fresh key — past sessions safe even if private key is stolen.
Interview Questions
Sign in to ask AriaWhat does HTTPS provide that HTTP does not?
Explain the TLS handshake at a high level.
What is Perfect Forward Secrecy and why does TLS 1.3 always enable it?
What is mutual TLS and how does it differ from regular TLS?
How would you configure HTTPS and mTLS in a Spring Boot microservice?
Ask Aria about HTTPS & TLS Handshake
Your personal AI tutor — ask anything about this concept
Revision Status
Personal Notes
Sign in to save personal notes for this topic.
Discussion
Sign in to join the discussion.