A timestamped signature on the binary would have it kept working and that's how MS intents it to work. You can leave it out if you have the desperate longing for having your software break suddenly without reason like Oculus just did.

Maybe they want beta versions to stop working, forcing users to upgrade.

For offline computers, it might be that some companies would see this as a way to enforce contract periods (customers would have to install an update to continue using the product when their contract is renewed).

Of course, disabling driver signature verification is still a way to bypass that, but often times the companies that do things like this probably aren't thinking about that.

Besides, literally every codesigning blogpost/tutorial/guide/etc I found tells you to use a timestamping server so the guys and girls and Oculus must have skipped the critical parts of whatever they used.

Security Solutions could benefit from this, the customer will have to update or disable the signature check if their version of the solution becomes too old. Old versions could open them up to vulnerabilities.

Another might be when you distribute beta or testing versions of your software. The customers can safely test the version and the lack of timestamp prevents them from running it in production permanently. They have to update to the release version.

It could also be useful when you sell a software to a business and want them to test it first. So you send them the program without a timestamp signature and limit the validity of the certificate. That way they can't just run the test version forever.

Really anywhere where all parties involved, user and producer, do not want to run a binary forever but the producer might not fully trust the user to do that.

In those cases, "we" (as a "community", in general) often blame the people responsible for running those services instead of the developers (or Amazon) being blamed for choosing convenience/ease-of-use over security. That is, we're often quick to say that the people running those wide open memcached servers are at fault for not properly configuring and/or securing them -- and not blaming the developers for creating "a giant footgun".

"You shouldn't be running servers on the Internet if you don't know how to properly configure them" (paraphrasing) is often stated. Yet, in this case, we're not blaming Oculus for their screwup and instead blaming Microsoft -- even though there's zero evidence (AFAIK) that Oculus even used any Microsoft tools to sign their application. (N.B.: I don't know the first thing about code signing on Windows so it may well be that using a Microsoft utility is required and, thus, just assumed by those of you who are familiar with the process. If that's the case, sorry.)

I'm having trouble trying to reconcile these two seemingly opposing viewpoints. Why is Microsoft's utility "a giant footgun" but a (OOTB) completely insecure by default, wide open by default memcached server (for example) isn't?

There's no reason for drivers to have an expiration date. There's no scenario where it makes sense for the configuration that Oculus stumbled into to be possible.

If you can license software with a definite expiration date, why can't you license hardware with a definite expiration date? And have your license enforced by the operating system? Imagine that I'm a company with a hardware product, and instead of selling that hardware at large expense, I rent it out, and provide drivers with an expiration date to enforce the terms of the hardware lease. If the lease is renewed, I'll provide new drivers with a new lease expiration.

Not that I'm arguing for hardware licensing, or arguing that it was what Oculus was trying to achieve and screwed up somehow. But there's a difference between "Microsoft built a feature some of their customers didn't know how to use" and "Microsoft built an anti-feature".

I'm not being facetious, FWIW. I know a fair amount about PKI, in general (probably in more depth and intricate detail than the average HN'er, actually), but I'm not a developer and I know very little about code signing in particular (and even less when it comes to the Microsoft world of code signing).

I do find it kinda hard to believe that there's no use case whatsoever for this particular configuration (code signing w/o an included timestamp from a TTP), though. I certainly understand why a timestamp can be valuable (as it would in this case) but what isn't clear is that there is "no scenario" whatsoever where the lack of a timestamp might be acceptable or perhaps even desired.

As I said, though, I don't know enough about code signing specifically to know what these scenarios might be but I can't imagine there isn't even one of them.

I can readily imagine a scenario where a driver with a signature but no separately attested timestamp should be acceptable. What I cannot imagine is a scenario where it is useful to treat a driver signed in such manner the way Windows currently treats the driver.

I mean this with all respect... but why? You're talking about different opinions expressed by completely different people. HN isn't a monolith.

My point was: in most threads, there's a common opinion or viewpoint shared by most, along with a few "detractors". In general, though, the overwhelming "predominant" opinions (within/on a particular subject) are pretty consistent from one thread to the next.

For example, the "it's the end user's fault, not the developers" thing I mentioned earlier. That seems to be, pretty consistently, the "belief of the majority". Here, though, it's the complete opposite. Instead of saying "the end user (Oculus) screwed up" (which, IMO, they certainly did, FWIW), it's "Microsoft made a footgun which caused this".

That said, I have now made it through the rest of the comments in this thread and it seems that this viewpoint isn't as widespread as it first appeared. Perhaps I just jumped to a conclusion much too quickly; there's obviously plenty of fingers pointing at Oculus as well.

Am I getting this right?

Why aren't we blaming the people behind RFC5280, after all it was them who came up with this awful idea that certificates should expire.

>giant footgun

oh dear god how are you generating your certificates? This is not a footgun unless you are doing something immeasurably stupid before even involving MS products.

Besides, if you insist on going ahead and setting the Not After field, wouldn't it be a bigger footgun to ignore that?

However, I'd argue that disregarding the Validity section would be an unusually big departure from the spec, not comparable to the typical silliness surrounding x.509.

Alternatively you could propose no user configurable functionalities whatsoever and rarely and carefully upgrade any dependencies (including the os) and you will create a very robust program.

But then don’t expect to end up with a wireless VR headset with an online game catalog and multiplayer capability. No but you can up with a very nice banking application developed in COBOL for sure.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

read the command for signing their code, and signed their code as instructed.

Today, the certificate they signed a driver with expired, and because the signature wasn't timestamped it means Windows can't know if the driver was signed with the certificate after it expired, so the signature is now treated as expired as well, so Windows doesn't trust the driver.

Why wasn't it timestamped? Probably because instructions like the link above treat that as a separate subject to signing your code, and when you sign your code it looks and works like it's fully correctly signed.

or, as wtallis puts it (https://news.ycombinator.com/item?id=16542204), someone left a foot-gun lying around that didn't have much value except to cause incidents like this.

...and if your own company makes Windows apps, go check they are timestamped ;)

But you can also find places where Microsoft does talk about when you should be timestamping: https://blogs.msdn.microsoft.com/ieinternals/2011/03/22/ever...

Sure, further down it explains how to use signtool to timestamp something, but why would someone trying to get an app signed care about using the tool for timestamping?

> where Microsoft does talk about when you should be timestamping

If someone finds that article first, and reads to the bottom of it, it explains that timestamping is related and important and says the times you should be timestamping are "you should definitely do this", so perhaps a design that isn't a foot-gun would have "do this" as the default, with a --force option and alarmist warnings for anybody who has a reason to have their signed executables expire one day.

Design oversights and user mistakes like these will happen, but it doesn't mean influences and causes can't be identified and improved.

(most of the builds at the company I work for had not been timestamped either)

With a timestamp, as long as the signing date was within the signing cert's validity period, the signed driver continues to be trusted beyond the signing certificate expiration.

If the driver was valid when it was signed, then revoking it will break the system. Not installing it is another story.

Ideally it's not used except by the timestamp service, but it seems like a fairly reasonable fallback.

The fact that the driver was installed locally before the expiration should be taken as proof that the driver was signed before expiration.

You could look at the system clock but that was not designed to be secure for this purpose.

If you think I'm proposing any changes to how drivers are installed, then you have misread me. I'm proposing a change to how already-installed drivers are handled: absent any new information, the code that was trusted yesterday should be trusted today, and be allowed to keep running.

You could say that any damage has already been done which is most likely true. But I can't fault them from mitigating it as much as possible.

I suppose you could modify the system to get external attestation of the time while the driver is installed and use that as a sticky bit - but its a big complication and its much better if the driver is securely timestamped in the first place.

The only way that the system "knows better" is by acquiring something like a certificate revocation list. The system does not know whether it was powered down for five minutes while the network outage was fixed, or for five years. When the system is powered back on with a working internet connection, it does not have any reliable way to tell whether the offline installation of the network driver occurred prior to the expiration, or after the expiration with a properly backdated driver and backdated system clock. There is no way to justify suddenly de-trusting a driver that's already been running simply by observing that you're in the future.

I guess I don’t know the time when Microsoft has their code and heir contact information and is doing some kind of preflight check, or if that ever actually happens, and there are already so many ways to be very dumb with drivers...

how so? it merely limits which dates you can sign code, after which the code you signed remain valid, but you can't sign any more code.

The whole problem here is that the code that was signed is not being treated as valid code beyond the expiration date.

The fact that if a rootkit is in a position to performing that spoofing, it doesn't need to, because it already has the power to make arbitrary modifications to the system image.

CRL in the driver install flow implies being online (at some point) to install drivers too. As we move into the future it’s hard to imagine not having Internet access, but we also don’t design Windows. It’s definitely a case they’ve considered, though I did see mention of a timestamp server in this thread (I don’t know much about Windows signing, just X.509 PKI in general).

[Edit: It may not be this simple. See the top-level comment by r1ch about timestamp servers.]

Putting expiration dates on non-malicious drivers is not a particularly effective way to protect against malicious drivers.

I was replying to this part of your comment. It does seem worthwhile to validate the signature of the driver every time the driver is used if that check would reveal when a certificate has been revoked for having been compromised.

Agreed that the expiration time is not particularly useful for this purpose.

It would be much more efficient to scan the list of installed drivers every time a certificate revocation list is updated, because certificates are revoked much less often than operating systems are booted.

And there's nothing gained by just checking timestamps if you don't have a new certificate revocation list. If the driver is already installed and was trusted and running yesterday, you gain no security by deciding to not load and run that driver today, unless overnight you acquired new information that the driver is insecure or malicious. The ticking of a clock does not convey any such information.

I politely ask authors or publishers to release non-DRM ebooks when I can. Apart from best-sellers (or time sensitive books), I believe most books are stuck in the long tail of obscurity and releasing them as non-DRM won't affect their sales.

This also means I don't visit pirate websites that claim to have ebooks. It takes two to tango. :-)

That's not the future. That's the present! Which is even more worrying.

Generally this attitude doesn't backfire, because individual users loosing access to their data, their accounts or their software can be simply dismissed. But in this case it happened to everyone at once, so it's suddenly a big deal.

If one doesn't, well, she isn't much of a "security expert" after all, is she? Firewalling off TCP port 80/443 at your perimeter firewalls isn't a very good solution if you're an e-commerce company selling your product on your web site -- and the "security experts" know this.

Because Mark Zuckerberg said so, that’s why.

More relevant by the day: http://locusmag.com/2018/03/cory-doctorow-lets-get-better-at...