Which mechanism binds a client’s TLS session to a public key certificate to mitigate MITM attacks?

Which mechanism binds a client’s TLS session to a public key certificate to mitigate MITM attacks?

• A. Token Binding
• B. HTTP Public Key Pinning (HPKP)
• C. HSTS
• D. DNSSEC

Answer: (A)

Token Binding ties a client’s tokens to the actual TLS session by binding them to the TLS keying material derived from the client’s certificate/private key during the handshake. This means a token (like an OAuth token or session credential) can only be used over the specific TLS connection that established the binding. To validate the binding, the client proves possession of its private key, and the server verifies that the token is attached to that particular session. If an attacker intercepts the token, it won’t be usable on a different connection because the binding is missing the correct TLS key material. This per-session binding is what mitigates MITM scenarios where tokens could otherwise be reused or replayed. The other mechanisms don’t provide this exact session-level binding. Public Key Pinning (HPKP) pins keys to prevent accepting fraudulent certificates, but it doesn’t bind a specific TLS session to a token. HSTS simply forces HTTPS for a domain; it doesn’t tie tokens to a TLS session. DNSSEC ensures DNS integrity but does not secure or bind the TLS channel or tokens themselves.

Token Binding ties a client’s tokens to the actual TLS session by binding them to the TLS keying material derived from the client’s certificate/private key during the handshake. This means a token (like an OAuth token or session credential) can only be used over the specific TLS connection that established the binding. To validate the binding, the client proves possession of its private key, and the server verifies that the token is attached to that particular session. If an attacker intercepts the token, it won’t be usable on a different connection because the binding is missing the correct TLS key material. This per-session binding is what mitigates MITM scenarios where tokens could otherwise be reused or replayed.

The other mechanisms don’t provide this exact session-level binding. Public Key Pinning (HPKP) pins keys to prevent accepting fraudulent certificates, but it doesn’t bind a specific TLS session to a token. HSTS simply forces HTTPS for a domain; it doesn’t tie tokens to a TLS session. DNSSEC ensures DNS integrity but does not secure or bind the TLS channel or tokens themselves.