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.
Since I set up a https website (lemmy) and had to deal with the hassle of certificates, I do wonder why you need another entity to churn out what’s basically a RSA key pair?
Is it this you must trust the government again or is there some better reasons for it?
It’s to make sure you’re actually reaching your intended endpoint. If I’m visiting a site for the first time, how do I know I actually have THEIR certificate? If it’s self generated, anybody could sign a certificate claiming to be anybody else. The current system is to use authority figures who validate certificates are owned by the site you’re trying to visit. This means you have a secure connection AND know you’re interacting with the correct site.
Sure, just convince the creators and maintainers of important software certificate stores to add your trust root. For example: Google, Mozilla, Microsoft, Apple, Linux, Cisco, Oracle, Java, Visa.
Your browser and/or OS has a list of trusted certs called “certificate authorities”. When it receives a cert from a web site, it checks that it was signed by a CA. So what you’re asking is to become your own CA.
That basically means convincing Mozilla, Microsoft, Google, Apple, etc. that you know how to safely manage certs. It tends to be a pretty high bar. For example, many CAs have a root cert that they keep locked away in a safe that only a few people have access to behind several other layers of security. They have a secondary key that’s signed by the root, and the secondary key is used to sign actual customer certificates. That way, they can expire the secondary every year or so and only ever use the root when they need a new secondary. IIRC, Let’s Encrypt has two secondaries with overlapping expiration times.
So to answer your question, no, not unless you’re willing to go to great lengths and have a great deal of knowledge about TLS.
I don’t know what the process is like to become a certificate authority. I imagine the answer is technically yes but realistically no, at least not as an individual. You’d be providing a critical piece of internet infrastructure, so you’d need the world to consider you capable of providing the service reliably while also capable of securing the keys used to sign certificates so they can’t be forged. It’s a big responsibility that involves putting a LOT of trust in the authority, so I don’t think it’s taken very lightly.
Correct, though to be pedantic anyone can be a CA- you just generate a cert with the right bits to say it’s a ca certificate and then use it to sign any other certificate you want.
But the only devices that will consider your signature worth anything are ones you also install your ca certificate on. So it’s useful and common in internal networks but isn’t really what is being asked here.
The hard part is getting in the root CA store of operating systems and browsers. As far as I know they are all maintained independently with their own requirements.
The security of these certificates only guarantees that you’re talking to the right server and that your communication is encrypted. For other concerns like of the server was hacked, you’ll need something else. No individual piece of security tech can secure everything. You as the site admin can only use it as one piece of a comprehensive security package that defends against what you perceive as the most credible threats.
Asking where’s the security is like asking where’s the protection with a bullet proof vest if you can still get shot in the head. A vest offers one type of protection, but a comprehensive security package is going to include other pieces like helmets.
Well it stands to reason, that TLS, i.e. Transport-Layer-Security, would secure the transport, and not secure the server providing the service against intrusion.
Also how is your hypothetical related to cost of certificates? If you use an expensive certificate with in person validation of your organization and its ownership of the domain name (these types of certs exist), then how does that change the case where your site is hacked, compared to the free certificate?
A certificate fundamentally only does the following, it binds a name and a public key together and attaches a signature to that binding.
Anyone can make a certificate binding any key to any name and put their own signature on it, they just can’t fake others people’s signatures. This is also what you do if you self sign a certificate. If you then install the public key of your signing key in your webbrowser you can connect to your own services using your TLS key and your browser will check that the server presents the certificate with a matchign signature proving that it is using the right TLS key.
You can also bind your TLS key to www.wikipedia.org and sign it. However nobody else knows your signing key, and thus nobody would trust the certificate you signed. Which is a good thing, because otherwise it would be easy for you to impersonate Wikipedia’s website.
The value of trusted certificates lies in the established trust between the signers (CAs) and the software developers who make browsers etc. The signers will only sign certificates to bind names and TLS keys for the people who actually own the name, and not for third parties.
The validation of ownership is the thing that varies a lot. The simple way is just checking for control of the web server currently reachable under a name, or checking for control of the DNS entries for a name, but the more complicated validations check business records etc.
So when you’re asking do they protect better, it’s kind of difficult to say.
If you can validate the signature yourself, say you have control of the browser and the server, then your own signature is fine, and a trusted one wouldn’t be any better.
But if you want third parties, that don’t know you, to be able to verify that their TLS session is established to a person who actually owns the domain, rather than a man in the middle, then the only practical solution today is using that established trust system.
If you are asking about the encryption strength of the TLS session itself, then that’s completely independent of the certificate issue, because again the certificate only binds a name to a key with a signature. You can bind an old short key, whose private key has been leaked before to a name, or you can bind a modern long key that is freshly generated to the same name. You can used either key in a good or a bad cryptographic setup. You can use deprecated SSL 3.0 or modern TLS 1.3. Those choices don’t depend on who signs the certificate.
Not at all, thank you for actually trying to answer my question instead of just telling me how it is supposed to work!
Just quickly, no I didn’t wonder about the keys encryption strength, what I do wonder about is if it is overall more secure to use a “trusted” entity, than, if the browsers weren’t locked down, my own home-generated signature.
I mean, if someone tries to “man in the middle”, or maskerade as my website, the trusted stuff will not add any security.
If someone hacks my site, and then maskerades as me (or does their shenanigans) the trusted stuff doesn’t add any security there either. They can just use my installed all set up “Trusted tm” certificate until it expires (my home made cert will expire too BTW).
So, for now, I don’t see any benefit to this except the trusted entity gets to have control over it all (and earn some money).
I bet there are smarter people than me out there who knows why I’m wrong, hence all the noobie questions.
I mean, if someone tries to “man in the middle”, or maskerade as my website, the trusted stuff will not add any security.
As long as they can obtain a certificate signed by a trusted signer for your name, you are correct. And you are touching on a real issue here. The number of trusted signers in the browser stores is large, and if only one can be tricked or compromised, then the MitM can generate a certificate your browser would trust just as well as your own original one.
If someone hacks my site […]
then it’s over anyway, yes. The signature on the certificate only validates your TLS key as being one that was properly assigned to the holder of your domain name. Once the endpoint is compromised, TLS doesn’t matter anymore.
if the browsers weren’t locked down
Actually maybe they aren’t as locked down as you think. To my knowledge you can add your own signing key certificates to your local installation of Firefox, Chrome and the Windows cert storage. In fact there are companies who do this a lot. They Man-in-the-Middle all their employees, with a proxy that does security scanning. For this reason they will deploy their signing keys internally. So the browsers still work. You can use these mechanisms for yourself if you like.
because if you roll your own root cert, nobody’s web browsers will see it as trusted, they all will warn the user that something weird is happening and treat the site as if it was plain HTTP. no lemmy server would federate with it for the same reason.
You can distribute your public key, and have people manually add it to their trust stores.
But OSs and browsers ship with preloaded trusted certificates. This way, the owner of a preloaded trusted certificate can issue new certificates that are automatically trusted by people’s OSs and browsers.
To become a preloaded trusted certificate owner, I imagine that there are stringent audits and security requirements. Part of that will be verifying the identity of the requester before issuing them a certificate.
With LetsEncrypt, they either need to talk to a server hosted at the domain to retrieve a token (generated when the request is initiated).
This proves the requester owns/controls the domain and the server (the requester has correctly set up DNS records, and placed the required token on the server). This is HTTP challenge mode.
The other method is by a DNS challenge. The requester adds a TXT record to their nameservers with the token value, letsencrypt then inspects the DNS records for the domain and will issue a cert when it sees the token. This proves the requester owns/controls the domain.
So, proving identity is required (otherwise anyone could generate a trusted cert for any domain). And trusted certificate issuers are required, so people don’t have to constantly import (possibly dodgy) public keys
And how does the client validate that your public key is actually your public key and not some attacker’s?
The idea of having a trusted 3rd party is to ensure that some impartial and trustworthy arbiter can confirm to the client that yes, this certificate is trustworthy, because they issued it to the correct party.
But you can absolutely self-sign a certificate. Works just fine, though not all clients accept self-signed certificates as trustworthy as anyone could have issued it.
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.
Sure, but the first time the other person would have to accept your self signed cert.
There is no knowing that the cert presented the first time was actually from you and not someone else.
You can make your own cert. To make sure your cert belongs to you (your site) it is signed by authority and the client then may verify that authority (which cetificate is preinstalled in their system) in fact had verified ownership of your site and then signed your cert claims with their private key.
Since I set up a https website (lemmy) and had to deal with the hassle of certificates, I do wonder why you need another entity to churn out what’s basically a RSA key pair?
Is it this you must trust the government again or is there some better reasons for it?
It’s to make sure you’re actually reaching your intended endpoint. If I’m visiting a site for the first time, how do I know I actually have THEIR certificate? If it’s self generated, anybody could sign a certificate claiming to be anybody else. The current system is to use authority figures who validate certificates are owned by the site you’re trying to visit. This means you have a secure connection AND know you’re interacting with the correct site.
Okay fair enough, but can I be a trusted entity and offer that service?
Sure, just convince the creators and maintainers of important software certificate stores to add your trust root. For example: Google, Mozilla, Microsoft, Apple, Linux, Cisco, Oracle, Java, Visa.
Your browser and/or OS has a list of trusted certs called “certificate authorities”. When it receives a cert from a web site, it checks that it was signed by a CA. So what you’re asking is to become your own CA.
That basically means convincing Mozilla, Microsoft, Google, Apple, etc. that you know how to safely manage certs. It tends to be a pretty high bar. For example, many CAs have a root cert that they keep locked away in a safe that only a few people have access to behind several other layers of security. They have a secondary key that’s signed by the root, and the secondary key is used to sign actual customer certificates. That way, they can expire the secondary every year or so and only ever use the root when they need a new secondary. IIRC, Let’s Encrypt has two secondaries with overlapping expiration times.
So to answer your question, no, not unless you’re willing to go to great lengths and have a great deal of knowledge about TLS.
I don’t know what the process is like to become a certificate authority. I imagine the answer is technically yes but realistically no, at least not as an individual. You’d be providing a critical piece of internet infrastructure, so you’d need the world to consider you capable of providing the service reliably while also capable of securing the keys used to sign certificates so they can’t be forged. It’s a big responsibility that involves putting a LOT of trust in the authority, so I don’t think it’s taken very lightly.
Correct, though to be pedantic anyone can be a CA- you just generate a cert with the right bits to say it’s a ca certificate and then use it to sign any other certificate you want.
But the only devices that will consider your signature worth anything are ones you also install your ca certificate on. So it’s useful and common in internal networks but isn’t really what is being asked here.
The hard part is getting in the root CA store of operating systems and browsers. As far as I know they are all maintained independently with their own requirements.
Question, if I can get free valud certs today (there atey sites that give you free ones, I use one for my lemmy site), where’s the security?
I mean it’s secure against man in the middle, but if my site is hacked, no proof is going to prevent the hackers to distribute whatever they want.
The security of these certificates only guarantees that you’re talking to the right server and that your communication is encrypted. For other concerns like of the server was hacked, you’ll need something else. No individual piece of security tech can secure everything. You as the site admin can only use it as one piece of a comprehensive security package that defends against what you perceive as the most credible threats.
Asking where’s the security is like asking where’s the protection with a bullet proof vest if you can still get shot in the head. A vest offers one type of protection, but a comprehensive security package is going to include other pieces like helmets.
Well it stands to reason, that TLS, i.e. Transport-Layer-Security, would secure the transport, and not secure the server providing the service against intrusion.
Also how is your hypothetical related to cost of certificates? If you use an expensive certificate with in person validation of your organization and its ownership of the domain name (these types of certs exist), then how does that change the case where your site is hacked, compared to the free certificate?
I think there is a big misunderstanding here.
My question is why shall I use a trusted certificate instead of rolling my own, if it wasn’t enforced (or st least made inconvenient) by google & co.
Does their certs protect better in some way?
A certificate fundamentally only does the following, it binds a name and a public key together and attaches a signature to that binding.
Anyone can make a certificate binding any key to any name and put their own signature on it, they just can’t fake others people’s signatures. This is also what you do if you self sign a certificate. If you then install the public key of your signing key in your webbrowser you can connect to your own services using your TLS key and your browser will check that the server presents the certificate with a matchign signature proving that it is using the right TLS key.
You can also bind your TLS key to www.wikipedia.org and sign it. However nobody else knows your signing key, and thus nobody would trust the certificate you signed. Which is a good thing, because otherwise it would be easy for you to impersonate Wikipedia’s website.
The value of trusted certificates lies in the established trust between the signers (CAs) and the software developers who make browsers etc. The signers will only sign certificates to bind names and TLS keys for the people who actually own the name, and not for third parties.
The validation of ownership is the thing that varies a lot. The simple way is just checking for control of the web server currently reachable under a name, or checking for control of the DNS entries for a name, but the more complicated validations check business records etc.
So when you’re asking do they protect better, it’s kind of difficult to say.
I hope that helps, sorry for writing so much
Not at all, thank you for actually trying to answer my question instead of just telling me how it is supposed to work!
Just quickly, no I didn’t wonder about the keys encryption strength, what I do wonder about is if it is overall more secure to use a “trusted” entity, than, if the browsers weren’t locked down, my own home-generated signature.
I mean, if someone tries to “man in the middle”, or maskerade as my website, the trusted stuff will not add any security.
If someone hacks my site, and then maskerades as me (or does their shenanigans) the trusted stuff doesn’t add any security there either. They can just use my installed all set up “Trusted tm” certificate until it expires (my home made cert will expire too BTW).
So, for now, I don’t see any benefit to this except the trusted entity gets to have control over it all (and earn some money).
I bet there are smarter people than me out there who knows why I’m wrong, hence all the noobie questions.
Cheers!
As long as they can obtain a certificate signed by a trusted signer for your name, you are correct. And you are touching on a real issue here. The number of trusted signers in the browser stores is large, and if only one can be tricked or compromised, then the MitM can generate a certificate your browser would trust just as well as your own original one.
then it’s over anyway, yes. The signature on the certificate only validates your TLS key as being one that was properly assigned to the holder of your domain name. Once the endpoint is compromised, TLS doesn’t matter anymore.
Actually maybe they aren’t as locked down as you think. To my knowledge you can add your own signing key certificates to your local installation of Firefox, Chrome and the Windows cert storage. In fact there are companies who do this a lot. They Man-in-the-Middle all their employees, with a proxy that does security scanning. For this reason they will deploy their signing keys internally. So the browsers still work. You can use these mechanisms for yourself if you like.
Example documentation: https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
because if you roll your own root cert, nobody’s web browsers will see it as trusted, they all will warn the user that something weird is happening and treat the site as if it was plain HTTP. no lemmy server would federate with it for the same reason.
Certificates are to protect against MitM attacks, not prevent your site from getting hacked. You need to secure everything, this is one aspect of it
So why can’t I make my own cert? Give the caller my public key and on we go.
You can distribute your public key, and have people manually add it to their trust stores.
But OSs and browsers ship with preloaded trusted certificates. This way, the owner of a preloaded trusted certificate can issue new certificates that are automatically trusted by people’s OSs and browsers.
To become a preloaded trusted certificate owner, I imagine that there are stringent audits and security requirements. Part of that will be verifying the identity of the requester before issuing them a certificate.
With LetsEncrypt, they either need to talk to a server hosted at the domain to retrieve a token (generated when the request is initiated).
This proves the requester owns/controls the domain and the server (the requester has correctly set up DNS records, and placed the required token on the server). This is HTTP challenge mode.
The other method is by a DNS challenge. The requester adds a TXT record to their nameservers with the token value, letsencrypt then inspects the DNS records for the domain and will issue a cert when it sees the token. This proves the requester owns/controls the domain.
So, proving identity is required (otherwise anyone could generate a trusted cert for any domain). And trusted certificate issuers are required, so people don’t have to constantly import (possibly dodgy) public keys
And how does the client validate that your public key is actually your public key and not some attacker’s?
The idea of having a trusted 3rd party is to ensure that some impartial and trustworthy arbiter can confirm to the client that yes, this certificate is trustworthy, because they issued it to the correct party.
But you can absolutely self-sign a certificate. Works just fine, though not all clients accept self-signed certificates as trustworthy as anyone could have issued it.
Because they’ll use it and it’s I that verify by decrypting it with my private key? If someone makes him use a bad key then it just won’t work.
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?
Sure, but the first time the other person would have to accept your self signed cert. There is no knowing that the cert presented the first time was actually from you and not someone else.
How would that matter?
Say my website sends you my homemade cert, if you don’t use it you cant communicate with me (or go unsecure).
Why myst some “trusted entity” emit tjose certificates? They are just a bunch of RSA keys!
You can make your own cert. To make sure your cert belongs to you (your site) it is signed by authority and the client then may verify that authority (which cetificate is preinstalled in their system) in fact had verified ownership of your site and then signed your cert claims with their private key.