How can a user’s computer with a fresh browser installation connect securely to a website?
Modern browsers come with a preloaded set of trusted root Certificate Authorities (CAs)
When visiting a site (e.g., https://example.com), the browser checks that:
1. The site presents a valid digital certificate signed by a CA.
2. The CA is one of the trusted roots or part of a valid trust chain (root –> intermediate –> site certificate)
3. The certificate matches the domain and is within its validity period.
What is the purpose of digital certificates?
They bind a public key to an entity (such as a domain name) and are digitally signed by a trusted CA to prove authenticity.
What would web trust look like if certificates had not been invented?
We’d rely on manual trust mechanisms, like SSH’s “trust on first use” model – where users accept and remember a site’s key fingerprint themselves.
However, this scales poorly, creates usability risks, and is vulnerable to spoofing.
How does this contrast with today’s system?
Today’s CA-based model automates trust verification via cryptographic signatures and pre-trusted roots, allowing immediate, global trust without user intervention.
What is the purpose of the TLS/SSL handshake?
To securely establish a shared session key and verify the server’s (and optionally the client’s) identity before data transfers begins.
Outline the key steps in the TLS handshake.
- Client Hello: Client proposes supported protocol versions, cipher suites, and compression options
- Server Hello: Server selects protocol and cipher suite, and sends its digital certificate
- Certificate Verification: Client verifies the certificate using its trusted CA store.
- Key Exchange: Client generates a pre-master secret, encrypts it with the server’s public key, and sends it.
Both sides derive a session key from this shared secret. - Handshake finished: Each side sends an encrypted “Finished” message, confirming key agreement.
Secure communication begins using symmetric encryption.
What role do certificates play in this handshake?
They authenticate the server’s identity (and optionally the client), enabling trust in the public key used to encrypt the pre-master secret.
Why does SSL/TLS include negotiation of cryptographic protocols and ciphers?
- Backward compatibility: Allows older clients and servers to communicate using mutually supported cipher suites.
- Security flexibility: Enables adaptation to new standards – weaker algorithms can be phased out (e.g., SHA-1 –> SHA-256, RSA –> ECDHE)
What is another benefit of negotiation?
It allows a client-driven security preference – the client proposes its strongest supported ciphers first, improving connection security without breaking interoperability.
Why does TLS use asymmetric cryptography only during the handshake?
Asymmetric encryption (RSA/ECDHE) is computationally expensive, but only needed for authentication and key exchange.
What two benefits come from switching to symmetric cryptography for data transfer?
- Speed: Symmetric encryption (e.g., AES) is much faster and suitable for large data throughput.
- Efficiency: After handshake, both sides share the same session key, reducing CPU load and latency for the remainder of the connection.
What’s an example of this hybrid approach?
TLS may use RSA or ECDHE for the handshake and AES-GCM for data encryption.
What happens if the private key corresponding to a site’s certificate is stolen?
An attacker can impersonate the legitimate site, decrypt user traffic, or perform man-in-the-middle (MITM) attacks
How can the use of a stolen certificate be stopped?
- Certificate Revocation Lists (CRLs):
The CA publishes a signed list of revoked certificate serial numbers
Clients must download and check it (not always timely) - Online Certificate Status Protocol (OCSP):
Browser queries the CA’s server in real time to check if a certificate is still valid.
Faster and more up-to-date than CRLs.
What are weaknesses of revocation systems?
CRLs grow over time and can become large.
OSCP can suffer replay attacks or availability issues
Not all clients enforce revocation checking strictly.
What are client-side certificates used for?
They authenticate users to servers (as opposed to servers to clients), proving the user’s identity via a certificate issued by a trusted CA
What is one benefit of client-side certificates?
Provide strong, cryptographic authentication, eliminating passwords and reducing phishing or credential reuse risks.
What is one downside of client-side certificates?
Poor usability and management: Users find it difficult to install, back up, or transfer certificates
Not widely supported by consumer websites – most rely on username/password plus 2FA
Where are client certificates more common?
Enterprise environments, government systems, and secure VPN access – rarely in public banking or retail contexts.
