Krebsonsecurity.com has an expired SSL certificate(krebsonsecurity.com)
krebsonsecurity.com
Krebsonsecurity.com has an expired SSL certificate
https://krebsonsecurity.com/
66 comments
I never understood why browsers don't just go ahead and load websites with expired certificates and merely provide milder warnings for a few weeks/months. The expiration date doesn't mark any meaningful real-world event that indicates the private key might be compromised... it's just an expiration date. Why set off all the alarms and make the user freak out and make it so hard to visit the site as soon as the certificate becomes 1 millisecond too old? It seems to violate common sense.
That would open a new vector of attack where an attacker would simply have to compromise any of your previous certs; not necessarily an easy feat but still a new vector
In a world where you can simply compromise a cert of your choice we can get rid of the TLS theatre altogether.
No, the world we have is one where these expiry mishaps happen all the time, and everyone would be better served if certs had a warning expiration date in addition to the red alert one. It's the old "don't delete a customer the second they are late on a single payment" thing that everyone long recognizes as good practice.
No, the world we have is one where these expiry mishaps happen all the time, and everyone would be better served if certs had a warning expiration date in addition to the red alert one. It's the old "don't delete a customer the second they are late on a single payment" thing that everyone long recognizes as good practice.
A difference is non expired compromised certificates are usually revoked. Expired compromised certificates are generally not.
I think whole thing could be solved by having soft and hard expiry dates. It is an extensible format after all.
I think whole thing could be solved by having soft and hard expiry dates. It is an extensible format after all.
No it doesn't? All that happens is the previous cert would be accepted with a milder warning for a few weeks (not permanently) after you get a new one.
It's just a small grace window to let users still be able to use the site. Just like an expiration date on your milk. There's no need to toss it out immediately just because an extra nanosecond passed.
It's just a small grace window to let users still be able to use the site. Just like an expiration date on your milk. There's no need to toss it out immediately just because an extra nanosecond passed.
This would require everyone to understand that previous certs still require high-security for at least a few weeks post expiration. This is not something we can rely on people understanding.
Alternatively we could have people understand all certificates, regardless of expiration, are high security. Is there any reason someone would want to publicize an expired certificate? Additionally, I can think of a few existing reasons someone would avoid publicizing an expired certificate.
[deleted]
I'm pretty sure that most people, upon having one of their certs expire, do not find the private key and release it publicly. In fact they often generate a new cert from the same key...
Allowing bypass is the old way of doing things, and many non-browsers still allow it, so you should ideally hold on to old certs indefinitely, but at least for a short while.
I think this is reasonable for people dealing with SSL, like expecting a mechanic to know you change an oil filter when you change the oil.
Training users that "mild" warnings can be ignored is very bad for security, as users have trouble differentiating severity.
Hsts does not even give users a choice because nobody could come up with a scary enough warning.
Hsts does not even give users a choice because nobody could come up with a scary enough warning.
I'd argue the problem might be the opposite: people are willing to differentiate on some matters (not everything), but security folks fail to help them do so. They treat every warning like DEFCON 1, as if an expired certificate is remotely similar to a compromised one.
People already understand expiration dates aren't exact. They deal with it in all kinds of places. It's not a new concept.
People already understand expiration dates aren't exact. They deal with it in all kinds of places. It's not a new concept.
So what exactly do you want changed? A warning already comes up explaining what happened that a user can click through. Unless the website has opted into strict mode, in which case warnings cannot be bypassed, which seems very reasonable.
> People already understand expiration dates aren't exact. They deal with it in all kinds of places. It's not a new concept.
Try crossing the border with an expired passport and see how non-exact expiry dates are.
> People already understand expiration dates aren't exact. They deal with it in all kinds of places. It's not a new concept.
Try crossing the border with an expired passport and see how non-exact expiry dates are.
> So what exactly do you want changed? A warning already comes up explaining what happened that a user can click through. Unless the website has opted into strict mode, in which case warnings cannot be bypassed, which seems very reasonable.
I'm saying load the website by default; just display a warning that isn't too intrusive or alarming. As a starting point (not suggesting this is peak UX; it's just a starting point for the discussion): it could be just a small balloon notification on the padlock with black text, nothing in red or otherwise alarming (or maybe becoming more red as more time has passed). A little bit like the balloon Chrome displays for "Disable developer-mode extensions". It still lets you use the browser but also gets its point across.
> Try crossing the border with an expired passport and see how non-exact expiry dates are.
You couldn't think of expiration dates for things that aren't at the extreme? Maybe for actions whose gravity is a little bit more comparable to visiting a website than, say, crossing an international border?
I'm saying load the website by default; just display a warning that isn't too intrusive or alarming. As a starting point (not suggesting this is peak UX; it's just a starting point for the discussion): it could be just a small balloon notification on the padlock with black text, nothing in red or otherwise alarming (or maybe becoming more red as more time has passed). A little bit like the balloon Chrome displays for "Disable developer-mode extensions". It still lets you use the browser but also gets its point across.
> Try crossing the border with an expired passport and see how non-exact expiry dates are.
You couldn't think of expiration dates for things that aren't at the extreme? Maybe for actions whose gravity is a little bit more comparable to visiting a website than, say, crossing an international border?
Actually, i'd be totally fine with that in the run-up to the cert expiring. Although i wonder if it would really make a difference - would the site operator notice such a mild UI change. After all, if they were paying attention they would already have monitoring for cert expiry.
> You couldn't think of expiration dates for things that aren't at the extreme? Maybe for things whose gravity is a little bit more comparable to visiting a website than, say, crossing an international border?
Passports are a credential, so are certificates. Generally expiry dates are strictly enforced on credentials. Same thing applies to driver licenses, health cards, etc.
> You couldn't think of expiration dates for things that aren't at the extreme? Maybe for things whose gravity is a little bit more comparable to visiting a website than, say, crossing an international border?
Passports are a credential, so are certificates. Generally expiry dates are strictly enforced on credentials. Same thing applies to driver licenses, health cards, etc.
If your passport is expired, you don't get to cross. (Or maybe you still do! if you're returning to your home country.) Tough luck for you, but 1 person made a mistake, and 1 person faced the consequences. With an expired certificate, the users (of which there are many) are the ones paying the price, and they're not at fault all.
Also, people absolutely do accept expired credentials for some things. Not for others. It depends on the seriousness of the situation and the consequences (especially legal consequences) for failing to validate the IDs properly.
You simply can't just pretend visiting a website is anything remotely comparable to crossing a border or producing an ID for law enforcement no matter how much you insist on it, so I'm not going to entertain this anymore.
Also, people absolutely do accept expired credentials for some things. Not for others. It depends on the seriousness of the situation and the consequences (especially legal consequences) for failing to validate the IDs properly.
You simply can't just pretend visiting a website is anything remotely comparable to crossing a border or producing an ID for law enforcement no matter how much you insist on it, so I'm not going to entertain this anymore.
I use TLS to secure my online banking.
I use TLS to communicate about taxes.
Those are hardly trivial things.
If you don't like id documents as a comparison despite certificates literally being identity documents, you could compare it to business licenses instead.
The reason that food has imprecise expiry dates is because we don't know when food will actually go bad. We do know how it is distributed, so we make a guess and err a couple standard deviations on the side of caution. However, we know precisely when a certificate will expire. The standard deviation for a certificate expiring (ignoring clockskew) is 0. If we gave 5 standard deviations of warning time on a certificate, it would still be 0 warning.
I use TLS to communicate about taxes.
Those are hardly trivial things.
If you don't like id documents as a comparison despite certificates literally being identity documents, you could compare it to business licenses instead.
The reason that food has imprecise expiry dates is because we don't know when food will actually go bad. We do know how it is distributed, so we make a guess and err a couple standard deviations on the side of caution. However, we know precisely when a certificate will expire. The standard deviation for a certificate expiring (ignoring clockskew) is 0. If we gave 5 standard deviations of warning time on a certificate, it would still be 0 warning.
> I use TLS to secure my online banking. I use TLS to communicate about taxes. Those are hardly trivial things.
The problem with the current narrative is that we're coerced into using TLS for everything, including trivial things. If you don't, you - as the owner of the website - are punished in different ways, even if the consequences for the visitor are none. As a consequence the web is full of expiration alerts that only make people more confused.
The problem with the current narrative is that we're coerced into using TLS for everything, including trivial things. If you don't, you - as the owner of the website - are punished in different ways, even if the consequences for the visitor are none. As a consequence the web is full of expiration alerts that only make people more confused.
They're quite non-exact. Most countries won't allow you to cross with a valid certificate if the expiry date is within 6 months in the future.
Why should every browser pick a random expiration date to enforce when there is already one agreed upon by everyone and embedded in the certificate?
There might be an official standardized explanation for this but the way I see it, certificate expiry has two reasons:
1) It's an assurance that the verification of identities/servers (or whatever) behind the certificate is at least somewhat recent
2) Certificates imply a loose agreement between the certificate holder and the world that the certificate holder keeps the private key safe. The expiry date automatically ends that agreement.
Time is relevant in both cases but it's not that relevant that the timing is exact in web browsing. Identity verification is still about as fresh one day after expiry. The second case is a bit more critical but chances are certificate holders don't leak their private keys immediately after expiry.
Giving a "grace period" with noticeable but non-blocking warnings (something like the "this site recently had an account breach" popup in Firefox perhaps) might cause website operators to find out about the problem without disrupting the service. It would be a good idea to standardize the length of the grace period.
Off the top of my head I can only think of one situation that might turn problematic and that is when an expired certificate gets compromised. I'm not familiar with how CAs do it but I hope renewal automatically revokes the renewed certificate already. It would also need to be possible to explicitly revoke an expired certificate if something like a grace period existed.
1) It's an assurance that the verification of identities/servers (or whatever) behind the certificate is at least somewhat recent
2) Certificates imply a loose agreement between the certificate holder and the world that the certificate holder keeps the private key safe. The expiry date automatically ends that agreement.
Time is relevant in both cases but it's not that relevant that the timing is exact in web browsing. Identity verification is still about as fresh one day after expiry. The second case is a bit more critical but chances are certificate holders don't leak their private keys immediately after expiry.
Giving a "grace period" with noticeable but non-blocking warnings (something like the "this site recently had an account breach" popup in Firefox perhaps) might cause website operators to find out about the problem without disrupting the service. It would be a good idea to standardize the length of the grace period.
Off the top of my head I can only think of one situation that might turn problematic and that is when an expired certificate gets compromised. I'm not familiar with how CAs do it but I hope renewal automatically revokes the renewed certificate already. It would also need to be possible to explicitly revoke an expired certificate if something like a grace period existed.
Everyone is on lets encrypt nowadays, which means they had no say in they expiration date. They merely said yes to "take it or leave it".
Let's Encrypt users aren't going to have cert expiration problems though, the certs expire every 90 days forcing users to implement auto renewal from the very beginning.
Let's Encrypt provides tools to do it while cert renewal with other certificate authorities is manual in most cases.
Let's Encrypt provides tools to do it while cert renewal with other certificate authorities is manual in most cases.
I have personally experienced letsencrypt auto renewal failures. And I know other people on whose hobbyist servers it has failed too.
I don't remember how it happened - maybe it was user error, but even so it only manifested 3 months after set up, which is not always the most convenient time. And then it's 3 more months to see if the fix truly worked.
I don't remember how it happened - maybe it was user error, but even so it only manifested 3 months after set up, which is not always the most convenient time. And then it's 3 more months to see if the fix truly worked.
Same here. In my case it was a failure of my DNS providers API and lack of monitoring. Worked fine at first, failed eventually.
[deleted]
I think it makes more sense to give warnings in the 72 hours prior to expiration, rather than after. At least browser console warnings.
Or have two expires in a cert - soft and hard.
Or have two expires in a cert - soft and hard.
That's just... moving the expiration date. Why not provide those milder warnings BEFORE the current expiration date?
If there's just an arbitrary point in time where after which we start warning people and then another point where the cert expires... Why move "expiration" around.
If there's just an arbitrary point in time where after which we start warning people and then another point where the cert expires... Why move "expiration" around.
> That's just... moving the expiration date.
No it's not, you still get a (slightly) nagging warning. Just one that's much milder (without the red alert, fear-mongering, etc.) and still lets people use the site for a while.
> Why not provide those milder warnings BEFORE the current expiration date?
I indeed almost suggested this, but the problem is the site owner hasn't done anything wrong in that case, so the warning would be an actual false alarm.
No it's not, you still get a (slightly) nagging warning. Just one that's much milder (without the red alert, fear-mongering, etc.) and still lets people use the site for a while.
> Why not provide those milder warnings BEFORE the current expiration date?
I indeed almost suggested this, but the problem is the site owner hasn't done anything wrong in that case, so the warning would be an actual false alarm.
If you are a site operator whose using a certificate that expires in under a day, you are doing something wrong.
I feel like it would be better to show a warning earlier rather than after it expires.
Browsers could start showing warnings that a cert is expiring soon when something like 5% of the cert lifetime is left (with a max of like 1 month for some of those crazy long lifetime certs).
Browsers could start showing warnings that a cert is expiring soon when something like 5% of the cert lifetime is left (with a max of like 1 month for some of those crazy long lifetime certs).
> I feel like it would be better to show a warning earlier rather than after it expires.
The problem is this is an actual false alarm in that case; nothing has actually gone wrong. Nobody likes to get a warning about something that's still good before its expiration.
The problem is this is an actual false alarm in that case; nothing has actually gone wrong. Nobody likes to get a warning about something that's still good before its expiration.
Certificates have a great timespan like "do not use before" and "do not use after".
So you can't simply shown outdated certs because this make time totally useless. But you also can't shown cert from the future.
Other sad news - new browsers set that certs can have lifetime only for year and month: https://www.michalspacek.com/maximum-https-certificate-lifet... to effective fight against certs that are too long lifetime.
So this make a window for installing new cert exactly 42 days. And many people will fail on this trap soon.
So you can't simply shown outdated certs because this make time totally useless. But you also can't shown cert from the future.
Other sad news - new browsers set that certs can have lifetime only for year and month: https://www.michalspacek.com/maximum-https-certificate-lifet... to effective fight against certs that are too long lifetime.
So this make a window for installing new cert exactly 42 days. And many people will fail on this trap soon.
I personally think that TLS certificate expiry should be a server problem not a client problem.
The TLS server code is the piece that is using the certificate every time a page is requested.
Why doesn't server code log an error warning that the certificate is going to expire?
Why doesn't the server just stop serving connections when the cert has expired?
Stopping connections ought to get the attention of the service owner rather than force clients to use out-of-band mechanisms to reach the service owner.
Alternatively perhaps imminent expiry should be a trigger for renewal or some other alerting mechanism.
Is there a callback like this in current TLS API stacks that could be used to make this work? (I'm not super familiar with TLS server side APIs, I know there are client callbacks for certificate validation).
It would probably be wise to do the check carefully so as to not consume too many resources. A well thought out mechanism could trigger an external process for notification or even automatic renewal - even when needing to cross a privilege boundary, perhaps touching a file or an IPC message.
I think this would be slightly better than some of the current setups for things like Let's Encrypt that end up running many times unnecessarily. Would be a much better fit for resource constrained embedded devices.
[edited: added back a sentence I inadvertently removed]
The TLS server code is the piece that is using the certificate every time a page is requested.
Why doesn't server code log an error warning that the certificate is going to expire?
Why doesn't the server just stop serving connections when the cert has expired?
Stopping connections ought to get the attention of the service owner rather than force clients to use out-of-band mechanisms to reach the service owner.
Alternatively perhaps imminent expiry should be a trigger for renewal or some other alerting mechanism.
Is there a callback like this in current TLS API stacks that could be used to make this work? (I'm not super familiar with TLS server side APIs, I know there are client callbacks for certificate validation).
It would probably be wise to do the check carefully so as to not consume too many resources. A well thought out mechanism could trigger an external process for notification or even automatic renewal - even when needing to cross a privilege boundary, perhaps touching a file or an IPC message.
I think this would be slightly better than some of the current setups for things like Let's Encrypt that end up running many times unnecessarily. Would be a much better fit for resource constrained embedded devices.
[edited: added back a sentence I inadvertently removed]
Like many I've been burnt by this problem. I have a rule now where no certificate should ever be within 6 months of expiry, ideally we should renew every month.
Chuckle, happens to the best of us - obviously.
I'm surprised that Brian Krebs still uses Comodo.
Why not LetsEncrypt with automated renewal?
Why not LetsEncrypt with automated renewal?
While you're not paying for the cert, there is certainly still a cost involved.
What is it? Genuinely curious, as I am using and relying on LetsEncrypt
The cost to build and maintain the infrastructure to handle renewal and tests to verify such.
I would say the technical hurdle is about equal to comodo. What other cost is there?
Comodo is a renewal and updating an artifact (i.e. the actual cert), then you're done, vs. having to handle LE's API to deal with doing it 'automatically' and then carrying that forward. My point is simply that the cost is not zero.
There's already mature, widely adopted tools like certbot and acme.sh that do this automatically for you.
It may not be zero, but it's no more than Comodo.
It may not be zero, but it's no more than Comodo.
You can still just replace the cert manually like you would any other CA. It's just there's no official GUI to do it with LE and you have to do it more often.
I hate getting in arguments with a few sysadmins and certificate salespeople how long certificate periods are perfectly safe.
I’d rather have 5 year certs and rely more on revocation than have this stupid exercise where people must renew every year or 13 months that just so happens to collect tons of rent seeking income from a few firms.
It’s kind of like how the shift to non-expiring passwords. We were trying to correct for the risk of a compromised password by making it harder to have secure passwords. I think we’re better off with having really strong passwords that only ever get changed when necessary and allowing this my monitoring login actions for weird stuff.
I’d rather have 5 year certs and rely more on revocation than have this stupid exercise where people must renew every year or 13 months that just so happens to collect tons of rent seeking income from a few firms.
It’s kind of like how the shift to non-expiring passwords. We were trying to correct for the risk of a compromised password by making it harder to have secure passwords. I think we’re better off with having really strong passwords that only ever get changed when necessary and allowing this my monitoring login actions for weird stuff.
The password comparison doesn't really fit. We stopped requiring it because users behaved badly when forced and caused a net reduction in security.
Sysadmins dont pick their private key. They dont write the private key on a post it. None of the reasons for not doing password expiry apply here.
Primary benefit of shorter certificates is it probably makes it easier to punish CAs that dont follow the rules.
Sysadmins dont pick their private key. They dont write the private key on a post it. None of the reasons for not doing password expiry apply here.
Primary benefit of shorter certificates is it probably makes it easier to punish CAs that dont follow the rules.
> people must renew every year or 13 months that just so happens to collect tons of rent seeking income from a few firms
Isn’t it primarily free CAs like LE that are pushing for shorter expiration times?
IIRC the primary argument is not about security or safety, but rather that shorter certificate lifetimes encourage companies to automate certificate renewal/make it a regular part of their business routine. If you only have to renew a certificate every five years, then it’s really easy to forget.
Isn’t it primarily free CAs like LE that are pushing for shorter expiration times?
IIRC the primary argument is not about security or safety, but rather that shorter certificate lifetimes encourage companies to automate certificate renewal/make it a regular part of their business routine. If you only have to renew a certificate every five years, then it’s really easy to forget.
I think it’s just as easy to automate a monthly renewal as a five year renewal.
The argument that gets presented to me is that shorter times reduce the risk of someone compromising the cert and pretending to be the real server. But that risk requires a pretty motivated attacker to also compromise DNS or server farm and that probably doesn’t matter because they will plan around any renewal cycle.
The argument that gets presented to me is that shorter times reduce the risk of someone compromising the cert and pretending to be the real server. But that risk requires a pretty motivated attacker to also compromise DNS or server farm and that probably doesn’t matter because they will plan around any renewal cycle.
When you tell management "we need to automate this process that won't happen for 5 years", you're not going to get approval.
When you tell management "we need to automate this process that will happen every month", you will get approval.
It's not about the effort to automate the process, it's the opportunity cost of investing that effort.
When you tell management "we need to automate this process that will happen every month", you will get approval.
It's not about the effort to automate the process, it's the opportunity cost of investing that effort.
Revocation doesn't really work well. Attackers only have to DOS the connection to the revocation list, and then they can use the revoked certificate freely. The revocation checks fail often enough that browsers don't even show a warning when this happens.
This happened to braintree/paypal like a month ago.. and broke their API
Happens to all sorts of folks - https://venturebeat.com/2015/04/04/gmails-ssl-certificate-fo...
[deleted]
Assume this is deliberate, since real domain hijackers would use a valid cert. Also helps to ensure browser vendors don't disable cert validity bypass. Very clever.
Based on his tweet it sure seems like he forgot to renew, and this isn't some kind of genius move to keep anyone honest.
https://twitter.com/briankrebs/status/1328863446105010177
https://twitter.com/briankrebs/status/1328863446105010177
That tweet says "Despite what the browsers may be saying, the site is still safe to visit."
Is it though?
Asking people to ignore browser warnings seems like bad advice from a security expert.
Is it though?
Asking people to ignore browser warnings seems like bad advice from a security expert.
Yeah, I, too, found that to be a really odd piece of advice from a security expert.
If I were the Brian (but I'm not), I would have asked followers to not trust the site until the certificate issue is fixed, even though I "know" my site is still safe. I think the properly cautious attitude is to consider all bets being off when a certificate is invalid for whatever reason. There is no guarantee what your visitors are actually getting.
If I were the Brian (but I'm not), I would have asked followers to not trust the site until the certificate issue is fixed, even though I "know" my site is still safe. I think the properly cautious attitude is to consider all bets being off when a certificate is invalid for whatever reason. There is no guarantee what your visitors are actually getting.
Bias finds its way into every corner. And no, it's not safe unless you do some extensive analysis of the certificate in question. Is this actually a valid/genuine certificate, besides the timestamp? A normal user will have a hard time verifying that.
It's safe considering the threat model: the worst his site has seen is some DDOS attacks. With a MITM his site might end up hosting a 0-day, but hijacking is unlikely to begin with due to how low-profile his site is (outside of tech circles). And they'd have to attack DNS as well as his certificate.
Why don't systems that use certificates have a configurable webhook they call to warn of such things?
echo "certbot-auto renew --nginx" > /etc/cron.weekly/renew_certs.sh
Fake news designed to cut down on DDOS