Explain TLS Handshakes and HTTPS Traffic Inspection

Read the full interview experience this question came from →

Quick Overview

Explain TLS handshakes, certificate validation, and symmetric traffic protection, then distinguish HTTPS proxy interception from passive decryption.

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.

Read the full TikTok Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/TikTok
TikTok logo
TikTok
Sep 5, 2026
easySoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
0
0

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?
Loading comments...