This letter was originally published in our 2024 Annual Report.
The past year at ISRG has been a great one and I couldn’t be more proud of our staff, community, funders, and other partners that made it happen. Let’s Encrypt continues to thrive, serving more websites around the world than ever before with excellent security and stability. Our understanding of what it will take to make more privacy-preserving metrics more mainstream via our Divvi Up project is evolving in important ways.
The client has to be able to verify. They can’t trust your result. Imagine a man-in-the-middle attack; if someone intercepted all traffic between you and the client, including the cert exchange, how would either party figure out that traffic was being intercepted?
Client connects to website, but gets intercepted. Attacker provides own self-signed certificate to client. Client asks you to verify the certificate, but attacker can intercept that too and just reply the certificate is “totes cool bro just trust me”. You are none the wiser either, because the attacker can just decrypt client traffic and pretend they are the client by re-encrypting the data themselves.
With a Certificate Authority, the client can take the received cert and ask the CA “did you sign this?”. The CA will then tell you they didn’t, exposing the attacker’s fake cert. This works, because the CA is already a trusted entity. That trust is being extended to your website’s certificate validity and thus the website identity.
If he fully takes over your website there’s nothing you can do as a client to detect it. But that’s not the point of the certificate. The certificate is there to ensure you are communicating with the website/server you think you’re communicating with.
It ensures your communication is safe. In my example, the attacker doesn’t take over your website, he takes over some part of the network infrastructure between your website and the client, thus intercepting all the traffic. There’s a “man in the middle”, e.g. the website is safe, the client is safe, but the communication between them is not. The certificate ensures nobody is impersonating the website by intercepting all the traffic, ensuring the communication.
If the website does get compromised, the CA has the option to invalidate the certificate at your request, via some verification procedure. Thus it also defends against compromised servers, though it’s not the primary purpose for which they exist.
Okay, but (if the big ones didn’t enforce it) a home made cert would also stop a man in the middle attack.
And if I figure it’s compromised, I just deal with it through my hoster or on my home-lab server.
I just don’t see why it should be a “trusted” entity in there at all. I know today it is how it works but I feel we could and should do away with it (in magic wonderland I guess :-)
Okay, but (if the big ones didn’t enforce it) a home made cert would also stop a man in the middle attack.
It would not, because the “man in the middle” would simply provide their own, also self-signed certificate, to the client and the client would have no way of verifying that that certificate is not to be trusted. The client is unable to distinguish between your self-signed cert and the attacker’s. That’s why the CA is needed, to verify that the certificate is actually issued by whoever you think it is.
This is why browsers do not trust self-signed certificates. They can’t verify who that “self” is. Doing away with it is a massive security vulnerability.
How do they know you verified by decrypting?
The client has to be able to verify. They can’t trust your result. Imagine a man-in-the-middle attack; if someone intercepted all traffic between you and the client, including the cert exchange, how would either party figure out that traffic was being intercepted?
Client connects to website, but gets intercepted. Attacker provides own self-signed certificate to client. Client asks you to verify the certificate, but attacker can intercept that too and just reply the certificate is “totes cool bro just trust me”. You are none the wiser either, because the attacker can just decrypt client traffic and pretend they are the client by re-encrypting the data themselves.
With a Certificate Authority, the client can take the received cert and ask the CA “did you sign this?”. The CA will then tell you they didn’t, exposing the attacker’s fake cert. This works, because the CA is already a trusted entity. That trust is being extended to your website’s certificate validity and thus the website identity.
I see where you’re getting at, or so I think:
A malevolent user takes over my website and installs his non-authorised certificate => danger!
But I mean he can use my certificate, it’s already there, installed and set up to work?
If he fully takes over your website there’s nothing you can do as a client to detect it. But that’s not the point of the certificate. The certificate is there to ensure you are communicating with the website/server you think you’re communicating with.
It ensures your communication is safe. In my example, the attacker doesn’t take over your website, he takes over some part of the network infrastructure between your website and the client, thus intercepting all the traffic. There’s a “man in the middle”, e.g. the website is safe, the client is safe, but the communication between them is not. The certificate ensures nobody is impersonating the website by intercepting all the traffic, ensuring the communication.
If the website does get compromised, the CA has the option to invalidate the certificate at your request, via some verification procedure. Thus it also defends against compromised servers, though it’s not the primary purpose for which they exist.
Okay, but (if the big ones didn’t enforce it) a home made cert would also stop a man in the middle attack.
And if I figure it’s compromised, I just deal with it through my hoster or on my home-lab server.
I just don’t see why it should be a “trusted” entity in there at all. I know today it is how it works but I feel we could and should do away with it (in magic wonderland I guess :-)
It would not, because the “man in the middle” would simply provide their own, also self-signed certificate, to the client and the client would have no way of verifying that that certificate is not to be trusted. The client is unable to distinguish between your self-signed cert and the attacker’s. That’s why the CA is needed, to verify that the certificate is actually issued by whoever you think it is.
This is why browsers do not trust self-signed certificates. They can’t verify who that “self” is. Doing away with it is a massive security vulnerability.
Thanks for the explanation it does make sense.