# TLS and HTTPS > HTTPS is HTTP protected by TLS, which encrypts traffic, detects tampering, and usually authenticates the server to the client. In system design interviews, the key decisions are where TLS terminates, which internal connections also need protection, and how certificates and connection setup affect reliability and latency. Source: https://sysround.com/concepts/tls Updated: 2026-11-05 ## How tls and https works For a typical HTTPS request over HTTP/1.1 or HTTP/2, the client resolves the hostname, establishes a TCP connection, and then performs a TLS handshake before sending HTTP requests. HTTP/3 instead uses QUIC over UDP, with TLS 1.3 integrated into connection setup. In a typical full TLS 1.3 handshake, the client sends a ClientHello with supported cryptographic options, a key share, and usually the requested hostname through Server Name Indication (SNI). The server chooses compatible parameters and returns its own key share, followed by encrypted handshake messages containing its certificate and proof that it controls the corresponding private key. The client checks that the certificate covers the requested hostname, is within its validity period, and chains to a trusted certificate authority. The peers derive shared traffic keys from the key exchange and verify the handshake. The certificate authenticates the server; it does not directly encrypt every HTTP request. Once established, TLS uses efficient symmetric authenticated encryption to protect HTTP headers and bodies. For example, a request to https://api.example.com/login hides the password, cookies, and URL path from passive network observers. Destination IP addresses, traffic timing, and often the hostname remain observable. TLS protection ends at the component that terminates the connection. If a CDN or load balancer terminates client TLS, it can read the HTTP request; protecting its connection to the application requires a separate TLS connection with certificate validation. Mutual TLS, or mTLS, additionally authenticates the client with a certificate. Connections can carry many requests, so connection reuse avoids repeated setup. TLS 1.3 session resumption reduces handshake work; optional 0-RTT early data can reduce latency further, but it can be replayed and must not be treated as safe for arbitrary state-changing operations. ## Worked example: Budgeting HTTPS setup for a login endpoint Suppose a login client has a 60 ms round-trip time to an edge proxy. For a new TCP connection with a typical full TLS 1.3 handshake, budget roughly 60 ms for TCP setup and another 60 ms for TLS before sending the HTTP request, excluding DNS, packet loss, and processing time. A reused connection avoids those setup round trips. Terminate public TLS at the edge, then use a separate, certificate-validated TLS connection to the authentication service. The edge can read credentials, so it belongs inside the security boundary and must not log request bodies. Automate certificate renewal and alert before expiration. If early data is supported, disable it for login requests rather than assuming encrypted traffic cannot be replayed. ## Trade-offs - **Edge termination versus pass-through.** Terminating TLS at a proxy enables HTTP routing, filtering, and caching, while pass-through keeps decryption at the backend but limits HTTP-aware processing at that proxy. - **Internal encryption versus operational complexity.** Re-encrypting backend traffic protects another network hop but adds certificate validation, rotation, and failure modes to manage. - **Setup latency and compute.** New connections pay transport and TLS setup costs, so measure connection churn and reuse before assuming bulk encryption is the bottleneck. - **Certificate management becomes an availability dependency.** Expired certificates, incomplete chains, or failed trust-store updates can block otherwise healthy services, making automated renewal and monitoring essential. - **mTLS identity versus authorization.** Client certificates provide authenticated peer identity but require issuance and rotation infrastructure and do not determine which operations that peer may perform. - **TLS protection has limits.** TLS protects traffic between its endpoints, not plaintext in application memory, sensitive logs, compromised endpoints, or data stored on disk. ## When to use it in a system design interview - A design carries passwords, session cookies, personal data, or other sensitive information over a network. - You introduce a CDN, API gateway, or reverse proxy and need to specify where requests are decrypted. - Services or managed agents must authenticate each other across a network where location alone is not trusted. - Connection setup affects a latency target, or reconnect bursts could overwhelm an endpoint. - Clients connect to many external HTTPS hosts and must handle certificate validation failures safely. ## How to bring it up in the interview - Draw each protected hop explicitly: client to edge, edge to application, and application to downstream service. Say who terminates TLS and who can see plaintext. - Explain the handshake as negotiation, authenticated key exchange, and establishment of symmetric traffic keys; interviewers may probe hostname validation and why the certificate matters. - Separate transport security from user authentication and authorization. HTTPS protects a login request, but sessions and permission checks still need their own design. - Tie performance claims to connection behavior: distinguish new from reused connections, state your RTT assumptions, and expect questions about resumption and 0-RTT replay. - Describe certificate issuance, automatic renewal, expiration alerts, and safe rotation. For mTLS, expect follow-ups about compromised identities and trust-root changes. ## Common mistakes - Saying HTTPS uses the server's public key to encrypt all application data rather than establishing symmetric traffic keys. - Drawing one HTTPS arrow to a load balancer and assuming every downstream connection is automatically encrypted. - Disabling hostname or certificate validation to fix connectivity problems, which removes a critical defense against impersonation. - Confusing TLS with end-to-end encryption: a TLS-terminating server can read the content it receives. - Treating TLS 1.3 0-RTT as safe for payments or other state-changing requests without addressing replay. ## Interview questions where it comes up - [Design a login and authentication system](https://sysround.com/questions/design-authentication-system): Protecting passwords and session credentials requires HTTPS with explicit termination boundaries so proxies and internal hops do not silently expose secrets. - [Design a web crawler](https://sysround.com/questions/design-web-crawler): Fetching arbitrary HTTPS sites requires correct hostname and certificate validation, connection reuse, and bounded handling of handshake failures. - [Design a system to run commands across a fleet](https://sysround.com/questions/design-fleet-command-system): Secure command delivery requires authenticated, encrypted agent connections, with mTLS offering a concrete device-identity and certificate-lifecycle design. ## FAQ ### What is the difference between TLS and HTTPS? TLS is a protocol for protecting communication between endpoints. HTTPS is HTTP carried over a TLS-protected connection; TLS is also used by protocols other than HTTP. ### How many round trips does a TLS handshake take? A typical full TLS 1.3 handshake takes one network round trip before the client can send normal application data. With HTTPS over TCP, a new connection usually also needs one round trip for TCP setup, excluding DNS. TLS 1.2 commonly needs more handshake round trips, while resumption and QUIC change the setup path. ### Should TLS terminate at the load balancer or application server? Terminate at a load balancer when you need centralized certificate management and HTTP-aware routing or filtering. Use a separate validated TLS connection to the application if that hop also needs protection. Pass-through termination at the application is another option, but the load balancer generally cannot inspect HTTP content. ## Related concepts - [Reverse proxy](https://sysround.com/concepts/reverse-proxy) - [Load balancing](https://sysround.com/concepts/load-balancing) - [Content delivery networks (CDN)](https://sysround.com/concepts/cdn) - [Service mesh](https://sysround.com/concepts/service-mesh) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.