Hacker News Reader

Comment by makecheck | Hacker News Reader

I think "grace periods" should be a lot more common in software. Not every issue is the user's problem, and not every problem requires a drastic response.

For instance, they could have:

- Quietly noted the issue in a file somewhere, waited 24 hours, and checked again.

- If the problem was still present after 24 hours, they could have made the software discreetly submit a problem report to Apple (but still launch and work correctly).

- After 48 hours, they could issue a background notification to the user indicating that a problem has been detected in the program and to “please check for updates on the App Store”; but again, continue to work correctly.

Or in other words, there were only about a half dozen more reasonable things they could have done that didn't involve an Amazonian break-things-immediately type of response.

View on HN

But if a program keeps running with an invalid security certificate, what is the point of having the certificate at all? If the practice is 'let the program with an invalid cert run silently for 2 days', then you aren't gaining any security at all. Malware could do everything it needs in 48 hours.

For example, you could have a parameter on the cert that caused clients to probabilistically reject it 1/10000'th of the time when in the last month of the cert's lifetime (so there are really two deadlines, the probabilistic-failure one and the total-failure one). That would give you the same warning about the coming total failure, without hindring as many users.

Or you just set a calendar reminder up ahead of time or have something like nagios set up to bug you when you get close. Why make "expiration date" not mean expiration date?

If my driver's license expires and I drive, I'm breaking the law. Sure, a judge or cop could be lenient, but there is no legal requirement (or justification?) for them to do so.

You can generally keep driving a car for a few days after failing an inspection so you can take it to get fixed with minimal issues. EX: Cracked headlight, increases risks of a problem in the long term, but if it's working right now it's generally not an actual issue.

IMO, tossing up a quick warning for the next month after expiration seems like a reasonable solution. Sure, something failed, but expired certificates are almost never a sign of a real problem.

> You can generally keep driving a car for a few days after failing an inspection so you can take it to get fixed with minimal issues.

How does this have anything to do with the issue? With a mechanical object, you have risks and probability of failure. The certificate or driver's license or credit card doesn't _fail_, it expires.

It fails otherwise it would still be valid. The question is how you Handel failure. An expired certificate is clearly a lower risk than a revoked sertificate, so only haing one failure mode regardless of cause is unnessisary.

PS: With an expired license the number of days past expiration is important in most states. Wait long enough and you need to retake the driving test, so clearly before that point it's still somewhat valid.

> It fails otherwise it would still be valid.

You're confusing things. The validation fails, as in it doesn't meet a certain requirement, the certificate; it isn't damaged or otherwise broken. A mechanical object fails in that it takes physical damage. You're striving for some semantic technicality to save your argument and I just don't think it's important.

> An expired certificate is clearly a lower risk than a revoked certificate, so only having one failure mode regardless of cause is unnecessary.

Why? You're just throwing an assertion out there that is false and expecting me to believe it's true. Additionally, if there is a 2-day window where an invalid certificate is valid, then all that does is make the expiration date 2-days into the future. If the certificate's owner doesn't notice an invalid certificate until after it doesn't validate, then they won't notice until after the window anyway.

> PS: With an expired license the number of days past expiration is important in most states. Wait long enough and you need to retake the driving test, so clearly before that point it's still somewhat valid.

That doesn't mean an expired license is valid. That simply means there is an implicit expiration date for the validity of your driver's exam.

> Why?

Your not limited to a single response. You could turn the URL red for a week and then after that do a popup etc. hell you could stup a browser to ignore expiration dates with minimal impact.

Remember, certificates are not some binary entity. You can have high and low trust certificates ex: trust to sign OS code, trust to sign user land code etc.

Your stuck in binary terms which are useless from a security standpoint.

> You could turn the URL red for a week and then after that do a popup etc.

And what does this buy you? Nothing, honestly. It just means that the expiration date is a week in the future from the date on the certificate. _You aren't actually changing the problem, just renaming it._ We could show red a week before the certificate is set to expire _now_; what does a grace period buy anyone?

Also, there are still have users that don't understand how to check if you have an SSLed connection, and you expect them to make a judgment on if an expired certificate is safe?

> hell you could setup a browser to ignore expiration dates with minimal impact.

No, no you couldn't. This means that if an old key, or one you've lost, is compromised, someone would be able to impersonate you, and you may be _unable_ to revoke a certificate. At least now, there is a definite amount of time that a scenario like that could happen for, you're proposing it happen indefinitely.

Moreover, it also becomes a forced upgrade requirement, viz sha2 certs currently. Sure, some longer-lived certificates may not have been updated (or supported currently), but they're not the rule. Most sites updated though a matter of course and never realized the security implications.

Additionally, the revocation status of expired certificates isn't currently published. Granted, this is a bureaucratic decision, it keeps the CRL size much smaller than it would be otherwise. (And again, it assumes you still have the keys to revoke an old certificate!)

> Your stuck in binary terms which are useless from a security standpoint.

Right, security isn't a binary thing. However, it is often based upon binary things, as they are easy to check, understand, and present. I also resent you calling me "stuck" when you're essentially asking for the exact same thing, just differently.

any old key...

You can always revoke certificates.

what does a grace period buy anyone?

It avoids bad publicity and lost revenue. At some point you don't want to continue operating with old certificates, but breaking without warning is a terrable idea.

Crls don't often include old certificates to limit the size of the CRL.

You have warning. You know when it will expire the day you buy it.

You still haven't told me how a grace period is different from extending the expiry.

There is a fair amount of difference between "an invalid cert" and a certificate that is valid apart from having expired a day ago.

Then why not push the expiration back 2 days, which is effectively what the OP is proposing.

A reasonable thing to do instead is to give a warning like "The security certificate for app X is expiring in two days. Please update it" or something like that.

OR don't have expiration dates on a cert, if that is preferable.

You have to realize that "start warning the user two days before the expiration date" and "start warning the user on the expiration date, but give them a grace period of two days" is just an implementation detail, no?

I think this is a great example of certificate expirations working well and as expected. Clients should update their damn software.

Well as someone else pointed out, Snow Leopard users literally can't.

...and this is why long term support is so important. That was literally the best released OS of all time, it's a shame it's falling off the end of the train.

Software doesn't fall off the Apple train, it's bound, gagged, and shot in the back of the head before being thrown off while on a bridge over deep water.

There's minimal security risk in allowing a formerly-validated piece of software to remain usable so long as it is not modified by any updates that cannot be verified by a current certificate.

Being this strict at the cost of usability isn't about security, it's about DRM and making sure you don't get to keep using your software after the subscription has expired.

But these apps aren't paid for by subscription.

Every app store purchase is a subscription. If it were a purchase, you could resell. As you can't, it's clearly a rental model with payment up-front. Apple decides when they pull the plug on your 'purchase'. The same thing applies to google play, windows store, steam, etc... The era of buying software is drawing to a close. From here on out it's rental only, unless you follow the advice of rms and use libre software exclusively.

Probably more sensible and simple would just be a warning alert that pops up when launching an app with a certificate that will expire within X days.

Why does this matter to the end user?

This particular bit of verification has nothing whatsoever to do with security. It's an error in purchase verification. If the practice is to let the program run with an invalid purchase receipt for two days, then you're just giving pirates a free two-day trial. Some people might see that as a problem, but I personally value the experience of paying users over inconveniencing pirates.

Since the issue was actually applications that were using pre-2005 versions of OpenSSL that didn't support SHA-2, the "grace period" here was effectively 10 years.

Reply on news.ycombinator.com