What's the point of certificates in SSL/TLS?

Question

A valid certificate cannot guarantee that I'm not being MITM'd right now, as either the private key or CA may have been compromised. For this reason, I have to contact a CA through CRL/OCSP to check if it's been revoked. Best case, I can have a CA's signed confirmation stapled to a response from the server.

But if the CA has to be contacted anyway, why even bother with certificates? Why not just have the server staple me a signed response from the CA that says "This is Server's PubKey, signed CA 5 seconds ago", which I can trust since I have the CA's PubKey in my store.

The CA's message is far more important to me than the certificate. The certificate is only somewhat useful in the case that I'm offline, or the CA's entire infrastructure is offline, and I just have to hope that the certificate hasn't been compromised.

What's strange is that the literature I read on this subject seems to invert the significance of the certificates vs CRL/OCSP information.

Am I missing something here?

Answer 1

The signed CA response you envision is a certificate. Maybe not a classical X.509 certificate that we currently use, and maybe much more short-lived, but conceptually, it serves the exact same purpose as a certificate where a CA binds a public key to the identity of a particular server.

So instead of questioning the purpose of certificates, this seems to be more about increasing the frequency of validity checks. Sure, this could be done. But it would require CAs to significantly beef up their infrastructure, and it's questionable how much this would actually improve security. You assume that private keys get compromised all the time, and at the same time you assume that website owners somehow notice this immediately and inform their CA. In reality, certificate revocations are rare compared to the total number of certificates, either because website owners are pretty good at protecting their private keys, or because they don't notice when their key has been compromised. Even when they do notice, the time between the compromise and the actual notification of the CA can be pretty long. Putting seconds-level checks on top of this slow-moving process just isn't very helpful and could even create a false sense of security. The current model of relatively short-lived certificates, optionally coupled with OCSP, seems more appropriate.

Answer 2

Think of the certificate as an official signed statement confirming that the public key belongs to a particular host. The CRL/OCSP systems are there so that you can confirm that the official signed statement is still valid and that is still applies.

In reality, most browsers DO NOT actually check CRLs or use OCSP to check validity because that would be too slow. OCSP stapling does exist, but, as of now, it hasn't really taken off.

One of the reasons to "bother" with certificates is because you need to know WHOM to contact to confirm that the certificate is still valid. Without the certificate, you wouldn't know whom to contact or who the CA is. Another reason is so that there is a signed proof by the CA confirming that they did some checks to confirm ownership, etc. The certificate can contain the name and additional info of the organization, etc. The certificate also contains Certificate Transparency proofs, which are there to show that the CA published the fact that they had issued the certificate to a public log, and this serves to make sure that CAs don't misissue certificates, among other things, it keeps CAs in check, etc.

OCSP and CRLs don't tell you that "this is the public key of the server", instead, they tell you that you can trust whatever public key and other info is included in the certificate.

In general, the host using a certificate is supposed to keep the private key safe and there is the assumption that they will keep it safe.

Another issue with OCSP when the client makes the request to the CA is that it does not preserve privacy. The CA knows which (IP address) visits which host (website, domain). Also, if every client makes OCSP requests, the servers of the CA would receive significant traffic and require infrastructure upgrades to handle it.

The best and most practical scenario would be for the certificate (with Certificate Transparency information) to be accompanied by an OCSP response. The server preemptively and frequently asks for an OCSP response to have on hand and gives sends it to the client, along with the certificate. The same OCSP response can be sent to many clients, as long as it is still temporally valid. Also, since the server makes the OCSP request, the privacy of the client is preserved. The loading time is not increased, in any significant degree, since the client doesn't have to contact the CA for an OCSP response (or search through a huge CRL) and the cryptographic verification of the server-supplied OCSP response is quick. This is called OCSP Stapling; unfortunately, it hasn't taken off as of now.

Answer 3

"A valid certificate cannot guarantee that I'm not being MITM'd right now, since the certificate may have been compromised"

In practice, this is mostly a non issue, as for all practical purposes compromising the private key (the certificate itself is public) usually means (there was the Heartbleed exception) that an attacker gained administrator access on the machine. Once the attacker has done so he usually can do much more than just man in the middle people. Machines get compromised all the time, and clearly using compromised keys post compromission hasn't been as much as an issue than the outright data plundering, malware planting and other not so nice things that happens in such case.

Answer 4

I think it's important to look at the historical context here, because successful protocols are generally built on what came before, not designed from scratch.

Netscape first released SSL to the public in 1995; for authenticating the server, it made use of an already standardised system of certificates, X.509. The integration was very simple: the operator of a server pointed their configuration at a private key and a certificate signed by some trusted Certificate Authority, and that certificate would be sent with every SSL connection to be checked by the client.

In this system, certificate renewal was an entirely manual process, with certificates often being marked valid for multiple years. Servers had no facility for contacting a Certificate Authority; CRL and OCSP were ways for clients to contact the CA after receiving a certificate from the server. A shared hosting provider did not need to configure any CA-specific systems, they could just allow a user to upload two files (or three, for a separate intermediary chain).

When Let's Encrypt launched, nearly twenty years later, they issued certificates valid for only 90 days, explaining on their website that this was explicitly to encourage automation, and that they might consider even shorter validity in future. This requires server administrators to configure more complicated software to talk directly to the CA, with the trade-off that users no longer have to pay a commercial CA if they just need a basic certificate.

If this history had happened differently, it's possible that something like what you describe would have arisen: perhaps certificates could be issued with lifetimes on the order of hours or days, rather than months or years. There would still be a tradeoff - every renewal costs resources for both the CA and the server which needs the certificate, and the lifetime on the certificate serves a similar purpose to the lifetime of a response cache. There would also likely be a difference between a "full renewal" (re-confirming ownership of the certified name) and a "revocation check" (confirming that the private key was not listed as compromised). The main difference in the end is whether the server is making this distinction, or the client.