Microsoft's driver signing model has a mode that is a giant footgun with no redeeming value. Oculus is a victim of Microsoft's bad design. They weren't trying to build in a self-destruct timer for their whole product stack, and if they were, they wouldn't have used the driver signing certificate as the lynchpin.
I find this reasoning ("footgun", Microsoft's fault) interesting when compared to the prevalent HN opinions when it comes to, for example, (unsecured) redis and memcached servers being used in DDoS attacks, or even AWS S3 buckets (with confidential or even highly classified files) being -- inadvertantly -- left wide open to the public.
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?
> I'm having trouble trying to reconcile these two seemingly opposing viewpoints.
I mean this with all respect... but why? You're talking about different opinions expressed by completely different people. HN isn't a monolith.
Sure, there are plenty of different opinions here on HN. If there wasn't, these discussion threads would be boring and useless.
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.
There's a use case for redis and memcached being open to the network, and a failure mode if you don't properly separate your internal network from the public Internet. There's a use case for S3 buckets that are publicly readable, if they don't contain sensitive/private information. Those features have reason to exist, even though there's potential for misuse. Secure defaults would be nice, but can't eliminate these risks.
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.
Really? No reason whatsoever?
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.
> 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.
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.
> There's no reason for drivers to have an expiration date
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".
The driver signing system is not an effective way to implement an expiration date, if that is your goal. Driver signing enforcement can be disabled rather easily by skilled users. Licensing restrictions written into the code of the driver itself are harder to bypass. It also does not seem at all likely that Microsoft intended for the driver signing system to be usable as a time-based DRM mechanism like this.
Interesting. I would think that opening unsecured services on to the Internet at large is a big no-no; and that whoever sets the default-allow is the one who's setting the trap here. Yes, the admin should inspect any installation for traps, but that's, as you note, secondary to "don't ship software which has a highly convenient trap set up". Most software traditionally exposed to the Internet did manage to do that, back in the early 2000s (by shipping default config `interfaces=lo` or somesuch), nobody should get a free pass on that, MS or not.
you can't guard against every imaginable stupidity. you try but users will inevitably find a hole.
That's not how APIs work. You don't eliminate stupidity by thinking of each and every way the user could screw up. You simplify your API so there aren't so many ways to use it in the first place.
So instead of trying to conform to the x.509 spec MS should have just developed their own certificate validation scheme, because that would totally be less of a "footgun" than conforming to the spec.
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?
FWIW, there are basically no common implementations that fully conform to the x.509 spec. That thing is a bundle of unimplemented features.
Hence "trying to" :)
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.