EduardCyber.mil serving file downloads using TLS certificate which expired 3 days ago
So what? They keep shortening the validity length of these certificates, making them more and more of a pain to deal with.
Which is yet another chore. And it doesn’t add any security. A certificate expired yesterday proves I am who I am just as much as it did yesterday. As long as the validity length is shorter than how long it would take somebody to work out the private key from the public key, it is fine.
Shortening certificate periods is just their way of admitting that certification revocation lists are absolutely worthless.
Right. It's the same debate about how long authorization cookies or tokens should last. At one point in time--only one--authentication was performed in a provable enough manner that the certificate was issued. After that--it could be seconds, hours, days, years, or never--that assumption could become invalid.
Isn't that why certificates expire, and the expiry window is getting shorter and shorter? To keep up with the length of time it takes someone to crack a private key?
No. The sister comment gave the correct answer. It is because nobody checks revocation lists. I promise you there’s nobody out there who can factor a private key out of your certificate in 10, 40, 1000, or even 10,000 days.
I thought I remembered someone breaking one recently, but (unless I've found a different recent arxiv page) seems like it was done using keys that share a common prime factor. Oops!
When RSA Fails: Exploiting Prime Selection Vulnerabilities in Public Key Cryptography
This paper explores vulnerabilities in RSA cryptosystems that arise from improper prime number selection during key generation. We examine two primary attack vectors: Fermat's factorization method, which exploits RSA keys generated with primes that are too close together, and the Greatest Common Divisor (GCD) attack, which exploits keys that share a common prime factor. Drawing from landmark research including Heninger et al.'s ``Mining Your Ps and Qs'' study, which discovered over 64,000 vulnerable TLS hosts, and B{ö}ck's 2023 analysis of Fermat factorization in deployed systems, we demonstrate that these vulnerabilities remain prevalent in real-world cryptographic implementations. Our analysis reveals that weak random number generation in embedded devices is the primary cause of these failures, and we discuss mitigation strategies including proper entropy collection and prime validation checks.
It's also a "how much exposure do people have if the private key is compromised?"
Yes, its to make it so that a dedicated effort to break the key has it rotated before someone can impersonate it... its also a question of how big is the historical data window that an attacker has i̶f̶ when someone cracks the key?
An expired cert is a smell. It shows somebody isn't paying attention.
And a short expiration time absolutely increases security by reducing attack surface.
Or that someone asked to renewed it, one of their four bosses didn't sign off the apropriate form, the only person to take that form to whoever does the certs is on a vacation, person issuing certs needs all four of his bosses to sign it off, and one of those bosses has been DOGE-ed and not yet replaced.
expired letsencrypt cert on a raspberrypi at home smells of not paying attention... with governments, there are many, many points of failure.
It did until it got so short that it created a new potential attack surface — the scripts everyone is using to auto update them.
Compared to the manual processes these scripts replaced, I'd put more trust in the automations.
Which would make sense if they were valid for 10 years and somebody forgot about them. Not when they’re valid for, what is it now, 40 days?
An official government source is teaching users to ignore security warnings about expired certificates.
Mistakes happen, some automation failed and the certs did not renew on time, whatever. Does not inspire confidence but we all know it happens.
But then to just instruct users to click through the warning is very poor judgement on top of poor execution.
And in turn making revocation less & less of a pain. Since that was more of the pain, overall it's getting easier.
> Users on civilian network can continue downloads through the Advance tab in the error message.
Good stuff.
"We have sent you a OTP code of 459-312 please check your device and enter this code below"
Is there anything inherently insecure about an expired cert other than your browser just complaining about it?
No, but it reflects poorly on the maintainer. Plus, any browser complaint contributes to error fatigue. Users shouldn't just ignore these, and we shouldn't encourage them to ignore them just because we fail at securing our websites.
“No, but it reflects badly because it’s an error, and because it’s an error it contributes to error fatigue, which is bad” is a very verbose way to say that you don’t have an answer.
Your comment history reflects a persistent approach: insulting the person you're replying to.
Please reflect on the site guidelines. https://news.ycombinator.com/newsguidelines.html
There is a reason why certs have expiration dates. It's to control the damage after the site owner or someone else in the cert chain messes up. That doesn't mean expired certs are inherently not secure, only that you should still care about it and do your best to avoid using expired certs.
Expiries are a defence-in-depth that exist primarily for crypt hygiene, for example to protect from compromised keys. If the private key material is well protected, the risk is very low.
However, an org (particularaly a .mil) not renewing its TLS certs screams of extreme incompetence (which is exactly what expiries are meant to protect you from.)
Inherently, not really. An expired, unsigned or even incorrect (as in, the wrong domain is listed) certificate can be used to secure a connection just as well as a perfectly valid certificate.
Rather, the purpose of all of these systems (in theory) is to verify that the certificate belongs to the correct entity, and not some third party that happens to impersonate the original. It's not just security, but also verification: how do I know that the server that responds to example.com controls the domain name example.com .
The expiration date mainly exists to protect against 2 kinds of attacks: the first is that, if it didn't exist, if you somehow obtained a valid certificate for example.com, it'd just be valid forever. All I'd need to do is get a certificate for example.com at some point, sell the domain to another party and then I'd be able to impersonate the party that owns example.com forever. An expiration date limits the scope of that attack to however long the issued certificate was valid for (since I wouldn't be able to re-verify the certificate.)
The second is to reduce the value of a leaked certificate. If you assume that any certificate issued will leak at some point, regardless of how it's secured (because you don't know how it's stored), then the best thing you can do is make it so that the certificate has a limited lifespan. It's not a problem if a certificate from say, a month ago, leaks if the lifespan of the certificate was only 3 days.
Those are the on paper reasons to distrust expired certificates, but in practice the discussion is a bit more nuanced in ways you can't cleanly express in technical terms. In the case of a .mil domain (where the ways it can resolve are inherently limited because the entire TLD is owned by a single entity - the US military), it's mostly just really lazy and unprofessional. The US military has a budget of "yes"; they should be able to keep enough tech support around to renew their certificates both on time and to ensure that all their devices can handle cert rotations.
Similarly, within a network you fully control, the issues with a broken certificate setup mostly just come down to really annoying warnings rather than any actual insecurity; it's hard to argue that the device is being impersonated when it's literally sitting right across from you and you see the lights on it blink when you connect to it.
Most of the issues with bad certificate handling come into play only when you're dealing with an insecure network, where there's a ton of different parties that could plausibly resolve your request... like most of the internet. (The exception being specialty domains like .gov/.mil and other such TLDs that are owned by singular entities.)