What is the use case or benefit for the server admin?
as a server admin I wouldn’t want to keep renewing my cert.
can anyone help to explain?
Lets Encrypt certs tend to be renewed by a cronjob, anyway. The advantage is that if someone gets your cert without your knowledge, they have, at most, six days to make use of it.
That makes little sense. If they can get my certificate then I have different problems that ,a 6 day turnaround isn’t going to solve
Presumably, you’ve patched up whatever hole let them in.
… Seriously?
If someone got a hold of your certificate that is the security equivalent of the entire company being on fire. If they got my certs they likely will have my credit cards, my birth certificate, and my youngest daughter.
Thank God though that I can renew my certificates every 6 days, that will definitely help sole the problem.
Yeah but it’s just an extra layer. Why not, it’s automated and almost no-cost.
they likely will have my credit cards, my birth certificate, and my youngest daughter.
that’s… not how SSL works.
I think the implication is the infiltrator would have a lot of access already.
OK. Whatever hypothetical we want to think about here, we still want our cert to be renewed.
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.
- 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.
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!
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.
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
Give the caller my public key and on we go.
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.
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.
I understand their reasoning behind this, but I am not sure, this is such a good idea. Imagine Letsencrypt having technical issues or getting DDoS’d. If the certificates are valid for 90 days and are typically renewed well in advance, no real problem arises, but with only 6 days in total, you really can’t renew them all that much in advance, so this risk of lots of sites having expired certificates in such a situation appears quite large to me.
I volunteer to help with IT at a makerspace, and I hesitate to go for 6 day expiration times. As volunteers, we can’t always fix problems in a timely way like paid IT staff could. We try to automate the hell out of everything, but certs have gone a day or two without getting updated before.
That’s true, but it would also have to be a serious attack for LE to be down for 3 entire days. There are multiple providers for automated certs, so you could potentially just switch if needed.
The attack would only need to last for a day or two, and then everyone requesting updated certs when it stops could push enough people outside the 6-day window to cause problems. 6 days is probably long enough to not be a huge issue, but it’s getting close to problematic. Maybe change to 15 days, which should avoid the whole issue (people could update once/week and still have a spare week and a day to catch issues).
Most companies are not really suited for instant switching to a different cert service.
Most companies weren’t suited for automatic certs either, but now they are
No one forces you to use let’s encrypt certificates. Can just quickly switch to another one temporarily.
Yeah, if you notice within that 6-day window before it expires. If you don’t catch it, your service could be down while you fix it, and that’s bad.
Yeah you might be on vacation when it happens
Yeah you might be on vacation when it happens
What the fuck is a vacation?
It’s a recent European invention, where you travel to other countries without your army.
But what if my army gets sad without me? What if I bring just some army? Ya know, in a travel carrier.
And then you forget about CAA records and wonder why it’s not working
Don’t certs just create an ephemeral key pair that disappears after the session anyhow? What does cert validity period have to do with “This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event.”
I mean, it’s LE so I’m sure they know what their talking about. But…?
compromising a keypair is a huge win. lets you impersonate the domain. shorter validation periods = smaller windows of compromised situations.
basically the smaller you make the window the less manual intervention and the less complicated infrastructure gets. currently TLS systems need a way to invalidate certificates. get them down to a day and suddenly that need just disappears. vastly simplifying the code and the system. 6 days is a huge improvement over 90 days.
Ok, I slid right by the “compromised” word. Makes sense now.
you mean you slid right on by an understanding of how security infrastructure works. since one always assumes credentials will be compromised.
I mean I just missed that part.
The key pair you’re thinking of is just a singular key for a block cipher. That key needs to be generated/transmitted in a secure manner. Meaning that its security is dependent on the cert. The expiration time of that cert is what they’re aiming at.
I’m far from an expert on PKI, but isn’t the keypair used for the cert used for key exchange? Then in theory, if that key was compromised, it could allow an adversary to be able to capture and decrypt full sessions.
No. Perfect Forward Secrecy (ephemeral keys) prevents this type of replay.
Time for a dive, thanks.
Im also not an expert but i believe since there Is still an ephemeral DH key exchange happening an attacker needs to actively MITM while having the certificate private key to decrypt the session. Passive capturing wont work
Have you read about perfect forward secrecy?
When I look at the default list of trusted CAs in my browser, I get the feeling that certificate lifetimes isn’t the biggest issue with server certificates.
People who’d abuse trust into centralized PKI system are not real, they can’t hurt you, because if they abuse it, said system’s reputation will fall to zero, right?
Except it’s being regularly abused. LOL. And everybody is using it.
The sites I have most frequently have had to add expired certificates to use are US government websites. Particularly those affiliated with the military branches. It’s sad.
Yes X.509 is broken. If you’re a developer and not pinning certs, you’re doing it wrong.
Yeah, now imagine pinning certs that change weekly.
My first thought is that old school secure software (like claws-mail) treats a cert change as a minor security incident, asking you to confirm every time. Completely different school of thought.
You can pin to your own CA. Then it doesn’t matter if you want to update your certs frequently.
Right
What
What part are you confused about, and are you a developer?
Edit: why was I downvoted for asking this?
I’m a developer and would appreciate you going into more specifics about which certificates you suggest pinning.
I’m saying that if you’re a developer of software that communicates between two nodes across the internet, you shouldn’t rely on X.509 because the common root stores have historically been filled with compromised CAs, which would let someone with that CA decrypt and view the messages you send with TLS.
You should mint your own certs and pin their fingerprints so that your application will only send messages if the fingerprint of the cert on the other end matches your trusted cert.
OK, so cases where you control both ends of the communication. Thanks for the clarification.
And your software stops functioning after X years due to this.
Don’t do this, this is a bad idea.
Technically all certificates are pinned, especially with public CAs, most OS package the latest CA certs which will all go out of style within 10 years or so. You can see this by loading up any old distro or defunct version of windows.
Yeah, fuck the users. We can just slap “100% secure” on the box and who cares if some woman is raped and murdered because we decided not to follow best security practices, right? /s
Digicert, Sectigo, Globalsign: hold my beer, 1 day certificate, even better: on the fly certificate per client 😂
Which of them is free?
Free has zero value in the enterprise world if managing certificates is a nightmare. Certificate prices is insignificant when your average website is a 90.000€ project.
Exactly, enterprise world. Letsencrypt doesn’t aim for that.
Interesting. I use LetsEncrypt largely for internal services, of which I expose a handful externally, and I’ve been thinking of only opening the external port mapping for cert renewals. With this at 90 days, I was planning on doing this once/month or so, but maybe I’ll just go script it and try doing it every 2-3 days (and only leave the external ports open for the duration of the challenge/response).
I’m guessing my use-case is pretty abnormal, but it would be super cool if they had support for this use-case. I basically just want my router to handle static routes and have everything be E2EE even on my LAN. Shortening to 6 days is cool from a security standpoint, but a bit annoying for this use-case.
certbot has modules for most DNS providers as well.
Oh, awesome! I thought that was a manual process, so I’ve been using the regular method.
Looks like I have a new project for this weekend. My DNS is currently hosted at Cloudflare, so this should be pretty straightforward.
It’s kind of in line with their plan to get rid of OCSP: short certificate lifetimes keep CRLs short, so I get where they’re coming from (I think).
90 days of validity, which was once a short lifetime. Currently, Google is planning to enforce this as the maximum validity duration in their browser, and I’m sure Mozilla will follow, but it wouldn’t matter if they didn’t because no provider can afford to not support chromium based browsers.
I was expecting that they reduce the maximum situation to e.g. 30 days, but I guess they want to make the stricter rules optional first to make sure there are no issues.
I wonder how short this could conceivably go…
Dynamic generation. There is no certificate until user request.
Perfect, let’s also bind the certificate to a user session that is derived from a user fingerprint. That way the CA can track users across all sites
I just want to serve https, not get someone’s dick permanently installed in my ass
Increase how often the drones call the mothership, excellent.
deleted by creator
