7 ms·

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

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.

cortesoft 11y ago
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.
- Strilanc 11y ago
  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.
  - jimktrains2 11y ago
    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.
    - Retric 11y ago
      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.
      - jimktrains2 11y ago
        > 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.
        Retric 11y ago
        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.
        jimktrains2 11y ago
        > 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.
- abhorrence 11y ago
  There is a fair amount of difference between "an invalid cert" and a certificate that is valid apart from having expired a day ago.
  - cortesoft 11y 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.
    - pyre 11y ago
      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?
    - duaneb 11y ago
      I think this is a great example of certificate expirations working well and as expected. Clients should update their damn software.
      - cptskippy 11y ago
        Well as someone else pointed out, Snow Leopard users literally can't.
        duaneb 11y ago
        ...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.
        cptskippy 11y ago
        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.
- wtallis 11y ago
  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.
  - joosters 11y ago
    But these apps aren't paid for by subscription.
    - Joeri 11y ago
      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.
- jakejake 11y ago
  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.
  - jimktrains2 11y ago
    Why does this matter to the end user?
- mikeash 11y ago
  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.
dak1 11y ago
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.

cortesoft 11y ago

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.

Strilanc 11y ago
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.
- jimktrains2 11y ago
  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.
  - Retric 11y ago
    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.
    - jimktrains2 11y ago
      > 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.
      - Retric 11y ago
        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.
        jimktrains2 11y ago
        > 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.
abhorrence 11y ago
There is a fair amount of difference between "an invalid cert" and a certificate that is valid apart from having expired a day ago.
- cortesoft 11y 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.
  - pyre 11y ago
    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?
  - duaneb 11y ago
    I think this is a great example of certificate expirations working well and as expected. Clients should update their damn software.
    - cptskippy 11y ago
      Well as someone else pointed out, Snow Leopard users literally can't.
      - duaneb 11y ago
        ...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.
        cptskippy 11y ago
        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.
wtallis 11y ago
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.
- joosters 11y ago
  But these apps aren't paid for by subscription.
  - Joeri 11y ago
    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.
jakejake 11y ago
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.
- jimktrains2 11y ago
  Why does this matter to the end user?
mikeash 11y ago
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.

dak1 11y ago

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.