Explain TLS Handshakes and HTTPS Traffic Inspection
Company: TikTok
Role: Software Engineer
Category: Software Engineering Fundamentals
Difficulty: easy
Interview Round: Technical Screen
Explain how HTTPS protects a connection, including the TLS handshake and certificate verification. Then explain how development tools can inspect HTTPS traffic.
### Part 1 — Establish an authenticated connection
Describe a modern certificate-authenticated TLS handshake. State the version and key-agreement mode used for your explanation, and explain what the client verifies about the server certificate.
#### What This Part Should Cover
- Negotiation, key agreement, proof of server identity, and handshake integrity.
- Certificate-chain validation and matching the intended service identity.
### Part 2 — Protect application data
Does application-data transfer use symmetric or asymmetric cryptography? Explain how the traffic keys relate to the handshake and why saying that all handshake traffic uses asymmetric encryption is inaccurate.
#### What This Part Should Cover
- Separate roles for key agreement, digital signatures, and authenticated data encryption.
- Protection against modification as well as observation of application records.
### Part 3 — Inspect traffic during development
Compare a trusted intercepting proxy such as Charles with passive capture and decryption in Wireshark. Assume the application and test traffic are yours to debug.
#### What This Part Should Cover
- The trust and routing conditions required for a proxy to terminate TLS.
- The secrets needed to decrypt a passive capture.
- Why trusting a root certificate alone does not decrypt an arbitrary captured session.
### What a Strong Answer Covers
- A version-specific explanation rather than mixing legacy RSA key transport with modern ephemeral key agreement.
- Correct distinctions among capture, interception, certificate trust, and possession of traffic secrets.
- Recognition that application trust policies can prevent a development proxy from being accepted.
### Follow-up Questions
- Why is possession of a server's long-term private key generally insufficient to decrypt a captured TLS 1.3 session using ephemeral key agreement?
- Why might a browser accept a development proxy while an application on the same device rejects it?
Overview: Explain TLS handshakes, certificate validation, and symmetric traffic protection, then distinguish HTTPS proxy interception from passive decryption.
Explain how HTTPS protects a connection, including the TLS handshake and certificate verification. Then explain how development tools can inspect HTTPS traffic.
Part 1 — Establish an authenticated connection
Describe a modern certificate-authenticated TLS handshake. State the version and key-agreement mode used for your explanation, and explain what the client verifies about the server certificate.
What This Part Should Cover Guidance
Negotiation, key agreement, proof of server identity, and handshake integrity.
Certificate-chain validation and matching the intended service identity.
Part 2 — Protect application data
Does application-data transfer use symmetric or asymmetric cryptography? Explain how the traffic keys relate to the handshake and why saying that all handshake traffic uses asymmetric encryption is inaccurate.
What This Part Should Cover Guidance
Separate roles for key agreement, digital signatures, and authenticated data encryption.
Protection against modification as well as observation of application records.
Part 3 — Inspect traffic during development
Compare a trusted intercepting proxy such as Charles with passive capture and decryption in Wireshark. Assume the application and test traffic are yours to debug.
What This Part Should Cover Guidance
The trust and routing conditions required for a proxy to terminate TLS.
The secrets needed to decrypt a passive capture.
Why trusting a root certificate alone does not decrypt an arbitrary captured session.
What a Strong Answer Covers Guidance
A version-specific explanation rather than mixing legacy RSA key transport with modern ephemeral key agreement.
Correct distinctions among capture, interception, certificate trust, and possession of traffic secrets.
Recognition that application trust policies can prevent a development proxy from being accepted.
Follow-up Questions Guidance
Why is possession of a server's long-term private key generally insufficient to decrypt a captured TLS 1.3 session using ephemeral key agreement?
Why might a browser accept a development proxy while an application on the same device rejects it?