Question bank — HTTPS — TLS handshake, certificates, CA

False. It only guarantees you are talking securely to the real owner of that domain; a phishing site can hold a perfectly valid certificate. Authenticity is not honesty.

False. The path and query are encrypted, but the hostname travels in cleartext via SNI so the server knows which certificate to send. Only recent ECH/ESNI hides it.

False. The cryptography (AES, RSA/ECDHE) is identical; what a self-signed cert lacks is a chain of trust to a root, so the browser cannot verify identity.

False. The certificate holds the server's public key for authentication and key-bootstrap. The bulk symmetric key is derived fresh each session and never transmitted.

False. HTTPS is literally HTTP inside the TLS tunnel — the same GET/POST methods and status codes ride encrypted. See HTTP — methods, status codes.

False. TLS needs a reliable byte stream, so the TCP — three-way handshake (SYN, SYN-ACK, ACK) completes first; then the TLS handshake begins on top.

False. The secret $s=g^{ab}\mathrm{mod}p$ is never sent; each side computes it independently from its own private value and the other's public value.

False (with ECDHE). Ephemeral Diffie–Hellman throws away its key pair after each session, giving forward secrecy. It is true only for old-style RSA key transport, where the leaked key decrypts recorded pre-master secrets.

False. Finished is a MAC over the entire handshake transcript; it proves nobody tampered with the earlier cleartext negotiation messages. Dropping it would leave the algorithm negotiation attackable.

False for domain-validated certs. A basic CA only checks you control the domain. Vetting the organisation is a separate, pricier tier (OV/EV).

Asymmetric is used only to bootstrap and to sign — it is far too slow for bulk data. The fast symmetric key handles all page bytes. This hybrid split is the whole point of Symmetric vs Asymmetric Encryption.

The browser trusts a root CA baked into its trust store, not bank.com. Trust flows transitively: root → intermediate → leaf, each link a verified signature. See Public Key Infrastructure (PKI).

You verify with the signer's public key; only the signer holds the private key. Mixing these up inverts the entire security model of Digital Signatures & Hashing.

They are public, but each side contributes one, so neither party alone controls the derived key, and the pair makes every session's keys unique — defeating replay of an old handshake.

In RSA key transport the client alone generates it, then encrypts it with the server's public key. Only the master secret is computed by both via the PRF.

The hard problem is the discrete logarithm: recovering $a$ from $g^a\mathrm{mod}p$. Factoring is RSA's problem, a different assumption. See Diffie–Hellman Key Exchange.

An expired cert breaks the validity check, so the browser cannot trust it. Expiry limits the damage window if a key is quietly compromised, so it is a hard failure, not cosmetic.

TLS 1.3 still sends the certificate and Finished; it only pipelines the key share into ClientHello to save a round trip. Authentication is intact.

They see $g^a$ and $g^b$ but need $g^{ab}$; getting there requires solving the discrete log to recover $a$ or $b$, believed computationally infeasible.

So neither side can force a predictable key. If only one contributed randomness, a compromised or malicious peer could steer the key toward a weak or known value.

DH hides the secret from passive watchers but a MITM can run two DH exchanges and sit in the middle. The certificate authenticates whose public value you are combining with, killing the MITM.

The root keys are the anchor of trust; fetching them over the network would itself need something already trusted. Baking them in (an out-of-band, vendor-vetted step) bootstraps the whole chain.

A validly signed cert for attacker.com is still real — but it must not authenticate bank.com. Matching the requested host to the cert's name stops a valid cert being reused for the wrong site.

The PRF is one-way and stretches one secret into several independent keys (encryption, MAC, both directions) bound to this session's nonces, so a leak of one derived key does not reveal the others.

DNS only maps a name to an IP address; it does not prove the machine at that IP is genuine. That proof is TLS's job via the certificate.

The browser rejects it (a name-mismatch error). A cert for example.net cannot authenticate example.com, even if perfectly signed.

The handshake fails with no agreed suite; ServerHello cannot pick one, so no secure channel forms and the connection is aborted.

Verification may break because the browser cannot bridge the leaf to a trusted root. Some browsers fetch the missing intermediate, but a correct server should send the full chain.

Early data sent in 0-RTT is replayable — an attacker can resend it — so it must only carry idempotent, non-state-changing requests.

No. Only the HTTPS transfer is encrypted and integrity-checked; the HTTP one leaks cookies in cleartext, which is why "Secure" cookies refuse to travel over plain HTTP.

An attacker could forge certs for any domain, so that root must be revoked/distrusted and removed from trust stores — a catastrophic, industry-wide event, which is why roots are guarded offline.