What happens during an HTTPS TLS handshake?
Reported in X (Twitter) USA engineering loops. Security and networking question covering encryption, certificates, and performance.
Interview scenario
Often asked in X (Twitter) on-site or virtual loops at US offices (Bay Area, Seattle, NYC, Austin, and remote US). Prepare a clear spoken answer plus key trade-offs.
Model answer
Try answering aloud first
Cover trade-offs, structure, and a concrete example before revealing the baseline response.
How to frame this at X (Twitter): Connect your answer to measurable impact, clarity of thought, and trade-offs the team cares about. Below is a strong baseline response you can adapt with your own project examples.
HTTPS wraps HTTP in TLS. Simplified 1.3 handshake: client sends ClientHello (supported ciphers, key shares); server responds ServerHello, certificate chain, and key share; both derive session keys; encrypted application data follows.
Server proves identity via X.509 certificate signed by trusted CA—browser validates chain and hostname. Mutual TLS (mTLS) also requires client certificate for service-to-service auth.
Performance: TLS 1.3 reduces round trips vs 1.2; session resumption (tickets) avoids full handshake on repeat visits; HTTP/2 multiplexing over one connection.
Engineering relevance: terminate TLS at load balancer vs app; HSTS header; certificate rotation automation (Let's Encrypt); and debugging with openssl s_client.
Discussion
Comments (0)
Share how this question came up in your loop, or add tips for others preparing.
Log in to comment on this question.