Main content
Computers and the Internet
Course: Computers and the Internet > Unit 4
Lesson 6: Secure Internet protocolsDigital certificates
AP.CSP:
IOC‑2.B.5 (EK)
, IOC‑2.B.6 (EK)
The TLS protocol relies on public key encryption. The sending computer uses the public key of the receiving computer when encrypting data. Before that happens, though, TLS requires a step that is crucial to its security: the sender must verify the identity behind the public key.
A digital certificate, also known as a public key certificate or identity certificate, proves the ownership of an encryption key.
The need for certificates
What would happen if TLS did not include a certificate verification step?
Attackers have come up with ways to intercept a request from one computer to another computer on the Internet, such as through rogue access points.
From here, they can launch a man-in-the-middle (MITM) attack. Even though it's called a "man" in the middle attack, attackers come in all ages and genders. You can also think of it as a "masquerader in the middle".
First, during the process of setting up a secure connection with TLS, an attacker sends the client their own public key instead of the server’s public key.
After that, whenever the client encrypts data with the received public key, they're instead encrypting data with the attacker’s public key. The attacker can then decrypt the encrypted message, change it however they'd like, and re-encrypt it with the server’s public key before sending the data to the server.
To prevent a MiTM attack, the client needs to check the identity behind a public key. A digital certificate shows the identity behind a public key. However, if anyone can make them, how can a client trust the legitimacy of a digital certificate? In TLS, clients trust a digital certificate if it was generated by institutions known as certificate authorities.
Certificate authorities
A server that wants to communicate securely over TLS signs up with a certificate authority. The certificate authority verifies their ownership of the domain, signs the certificate with their own name and public key, and provides the signed certificate back to the server.
When the client inspects the certificate, it can see that a certificate authority is vouching for the authenticity of the public key. But it still has a decision to make: does it trust that certificate authority?
Clients generally come bundled with a list of trusted certificate authorities. For example, an Apple iPhone running iOS 10 trusts this list of certificate authorities.
Apple users then have to trust Apple to continually monitor that list to make sure each certificate authority is verifying domains properly.
You can imagine a chain of trust from the user to the server:
At each point, trust can be broken. If the user doesn't trust the client, they can override the client's default list of trusted certificate authorities. If a client no longer trusts a certificate authority, it will remove it from the list. If a certificate authority sees suspicious behavior from a server, it can revoke its certificate.
Intermediate certificate authorities
There are actually multiple levels of certificate authorities: the root certificate authority and intermediate certificate authority.
The root CA does not actually directly issue any digital certificates for servers. It only issues digital certificates for intermediate CAs that act on its behalf. The intermediate CAs can either issue digital certificates for another intermediate CA, or for a server directly.
Thus, there is another chain of trust, from the root CA to the server:
The layers of certificate authorities increase the security of the system. If a root CA discovers that an intermediate CA has been compromised by an attacker, they invalidate the certificates from that CA but continue trusting the certificates from their other intermediate CAs.
🔍 You can see the chain for yourself when you check the certificate for a secured website in the browser. If you click the lock next to the URL, the browser should offer a way to inspect the certificates.
🙋🏽🙋🏻♀️🙋🏿♂️Do you have any questions about this topic? We'd love to answer—just ask in the questions area below!
Want to join the conversation?
What is stopping a Man in the middle from "forging the signature" on these certificates?(11 votes)- Excellent question. One of the requirements of the sign/verify operations in cryptography is to prevent signature forgeries. A common way to achieve this is to "re-interpret" public key encryption (covered in this Online Data Security section).
You can informally view public-key encryption as using two building blocks: make_one_way_hard (i.e. use the private key) and make_reverse_way_easy (i.e. use the public key).
1) In public-key encryption, decrypting an encrypted message is hard without the private key. So, make_one_way_hard corresponds to this decryption. On the other hand, it is easy to encrypt a message with the public key. make_reverse_way_easy corresponds to this encryption. In other words, decryption is one way, and the reverse direction is encryption.
2) For authentication (i.e. sign/verify operations), forging a message is hard without the private key. So, make_one_way_hard corresponds to this sign (e.g. decrypt from (1) ). On the other hand, it is easy to verify a signature with the public key.
Math is often independent of the application. For example, 2x=4 represents a setting where x can correspond to finance (dollars), astronomical(planets), or biological (hair cells) applications. Indeed, the math used for the applications of public-key encryption or signature schemes can look quite similar.
Of course, this is a simplifying analogy, but I hope it provides a new way to think about public-key encryption.(15 votes)
Does the verification happen fully on the device or is a connection to CA's servers necessary every single time?
What prevents the "Man in the middle" from forging the entire connection? It's like when a parent pretends to be Santa and replies to letters, and the child has no real way of figuring out if that person really is Santa.
"Are you Santa?" "Oh yes, of course I am!"
From my understanding it is impossible to check if a certificate is legit while offline. It could be possible if the computer has a CA's public key pre-installed and uses it to request an explicit verification from the CA's server. (Because CA is the only one that can decrypt the message a computer can public-key-encrypt some password into the message asking to send it back as response using it's own public key. Which is something a hacker wouldn't be able to fake)
But this requirers every device to have a CA's public-key preinstalled. (Which is not that hard)
And wouldn't this cause enormous traffic for a CA's server?
So does the user ever contact the CA's servers or is it able to somehow check a certificate offline using only pre-installed utilities?(6 votes)
Does not having a certificate mean that the website uses rogue access points?(2 votes)- Hello, Shlok. An access point is merely what is used to access the internet. Websites cannot control what access point you use to access their server, as you could either use the one in your home or the one in the nearest coffee shop :)(2 votes)
- Does not having a certificate mean that the website uses rogue access points?(2 votes)
Why does the article say Pacific Daylight Time?(1 vote)
That's when the example certificate depicted in the image at the bottom of the article is said to expire. Because a certificate must expire at an exact, particular time, it is important to note what time zone the time of expiration is written for. Hope this helps!(1 vote)
Are private & public the same as digital certificates, and if they aren't then why(1 vote)- The "bad man" represents a malicious man-in-the-middle attacker.(1 vote)
What is stopping a Man? Sean Link what do you mean?(0 votes)
