Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All of Oculus’s Rift headsets have stopped working due to an expired certificate

techcrunch.com

Post reply on HN
Print view View original

141–150 of 390 posts

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#141

Post by wtallis »

Ajedi32 wrote: post #117
lopmotr wrote: post #81

Earlier quoted context omitted.

Something like that. Certificates aren't supposed to stop working just because they've expired! That would destroy all abandoned or poorly maintained software within a couple of years. This problem is deeper than forgetting to update it. It should never have caused a failure in the first place. Just the fact that the device apparently can't function at all without the internet is a problem too.

> Certificates aren't supposed to stop working just because they've expired! Except TLS certs. That's the whole point of those certs having an expiration date in the first place.

TLS certificate expiration tells your browser to stop downloading new pages from that site. It doesn't tell your browser to close the page that's already been rendered and is still on-screen.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#142

Post by gambler »

ahelwer wrote: post #27
rb808 wrote: post #17

Has anyone got a good way of managing certificates in the wild? With no real management and staff turnover I've seen a bunch of expired certificate problems. EDIT: presumably you need your client apps/libraries in the field write back when they use a cert that is <X months away from expiry.

You can use secret management systems like Azure Key Vault to auto-roll/renew secrets, but your applications have to be built to use such systems. (disclaimer: work for Azure, but not on Key Vault)

Feudal security at its best.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#143

Post by wtallis »

jsmthrowaway wrote: post #52
kbenson wrote: post #37

Earlier quoted context omitted.

I think that's better handled through a Certificate Revocation List (CRL), especially in this case where's it's fairly easy to enforce and keep up to date.

CRLs are pretty difficult to scale resiliently, though, for a number of applications. Same problem that led to OCSP stapling after OCSP became a thing. With CRLs you can at least take advantage of a CDN of some kind, but there are tradeoffs with your ability to operate a CRL securely doing that, too. CRL in the driver install flow implies being online (at some point) to install drivers too. As we move into the future…

Are driver CRLs any more challenging than the virus definitions already distributed through Windows Update?

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#144

Post by erikpukinskis »

adrianratnapala wrote: post #137
andrewmcwatters wrote: post #96

Earlier quoted context omitted.

I was just reading something here about Cairo and how it's easy to fall into slow code paths with it, and if you happened across falling into a slow code path, somewhere along the line, "you fucked up." When I read the comment I was immediately flabbergasted: no, someone else fucked up. It's not my fault someone wrote software that sets up undocumented traps for me to fall into. Or provided three ways to do something…

The problem in this case is much deeper than their fault / your fault. The problem is that in this industry we do (have to?) lean too much on the power of abstraction. Whether you are writing SQL or graphics code you are constantly told "just express what you want to express directly, and the system is smart enough to do things as efficiently as possible". But that might not be very efficient at all. The people who w…

Yes, you’re talking about the proliferation of declarative APIs over explicit, imperative ones.

My pet theory is that because we typically understand our needs before we understand the code paths required to fulfill them, our V1 APIs are usually a declarative “this is what should be” interface. Then we spend days or months making it happen and by the time we understand the required code paths, we’ve totally baked our expectations about the “make it so” API into our architecture.

Getting to a good, explicit, imperative API requires a whole nother step, and often a major refactor. You have to step back and ask “what is really happening now and can I conduct it more directly?”

... but by that time your code works and it hardly seems worth the effort.

But it is worth the effort. The declarative API will just get uglier as you add to it, and provide no real guidance about where future additions should go. Just throw another key in the config. Add another conditional. An imperative one will constrain your future choices about how additions can work, and therefore helps you clarify your domain model as you add to it.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#146

Post by gambler »

ryanlol wrote: post #116
wtallis wrote: post #112

Earlier quoted context omitted.

That puts the blame on Oculus, but the blame really should rest on Microsoft for enabling and enforcing a signature mode that shouldn't exist at all.

Does that really not sound ridiculous to you? Microsoft needs to be blamed for their certificate validation implementation because people might use it to make their software expire? Instead of just writing code that does so?

How about we stop blaming people who accidentally pressed figurative "system self-destruct" button and start asking why there are so many of those buttons everywhere? Nowadays this is a recurring theme. Simple mistakes leading to catastrophic failures at grand scale. "Just be more careful" doesn't cut it anymore, because in the software world there are just too many things to be careful about.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#147

Post by lunch »

gambler wrote: post #134
lunch wrote: post #126

A driver signed with any certificate that expires after July 29th, 2015, without time stamping, will work on Windows 10 until the certificate expires. https://docs.microsoft.com/en-us/windows-hardware/drivers/da...

What a horrible design decision. Instead of making a system that simply works or doesn't work Microsoft allowed everyone to produce apps which break at random times in the future. It's one of those "what could possibly go wrong?" cases.

Is there a default, or standard TTL for this type of certificate?

EDIT: Looks like the standard TTL for these code signing certificates is none, 1, 2, or 3 years.

https://www.entrustdatacard.com/products/categories/digital-...

https://www.globalsign.com/en/code-signing-certificate/

https://www.instantssl.com/ssl-certificate-products/code-sig...

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#148

Post by wolco »

wtallis wrote: post #141
Ajedi32 wrote: post #117

Earlier quoted context omitted.

> Certificates aren't supposed to stop working just because they've expired! Except TLS certs. That's the whole point of those certs having an expiration date in the first place.

TLS certificate expiration tells your browser to stop downloading new pages from that site. It doesn't tell your browser to close the page that's already been rendered and is still on-screen.

But you are making new requests to the Oculus api and that part is failing. You wouldn't expect the ajax requests to continue to work just because you left your browser open for years.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#149

Post by megaman22 »

0x0 wrote: post #62
mikeash wrote: post #35

This seems to be a somewhat common type of problem. I wonder if companies should routinely test on machines with the clock set one year into the future to catch them before they hit customers.

I think you'd run into other problems then, for example if your test machine needs to communicate with https sites powered by letsencrypt, all those sites will appear to use certs that "expired" at least 9 months ago.

It's a mess. At one point we had a backup domain controller that had gotten incorrectly setup as a time server, and was out of sync with the rest of the world, with a slight amount of drift. Randomly, our test servers would end up syncing time from that server at times, and wind up slightly off. When the time got slightly more than around five or ten minutes off, connections (over TLS encryption) from those boxes to our Lync IM servers would start failing, and weirdness would ensue. Reboot the box, or sometimes just sign in and out, and things would straighten out, for a while. Very spooky.

This was all years ago, so my recollection may be fuzzy, but I spent entirely too much time futzing with SIP traces and certs. Weird, weird things can result from time inconsistencies is my takeaway, however.

Re: All of Oculus’s Rift headsets have stopped working due to an expired certificate

#150

Post by olliej »

scrollaway wrote: post #76

This, and many incidents like it, makes me think that running tests 1/10/100 years in the future should be a standard feature of test runners and CI systems. (on by default)

The kicker of course is that if you set the date to something in the future you may have a pile of other services fail before your code is run — Basically any /other/ services that happen over TLS may fail (correctly as their certs have expired ;) ).
Post reply on HN