Time namespaces

Posted Sep 21, 2018 21:31 UTC (Fri) by amarao (guest, #87073)
Parent article: Time namespaces

I just realized a scenario where time namespaces are excellent. It's the access to expired SSL. Yes, you shouldn't trust expired certificates. But what if some device have hardcoded certificate and it expired in 2016? Device (f.e. ip camera made of chainizium) is good and can be used. But it had certificate expiring on 2016... Currently it's pain in the arse to use such stuff, and every next browser version made it harder and harder. With time namespaces I can just run a browser instance in namespace with eternal 2015 and use such device with no issues.

Time namespaces

Posted Sep 21, 2018 21:47 UTC (Fri) by dtlin (subscriber, #36537) [Link]

If you just need to adjust the time for a single browser, libfaketime would likely be easier.

Chrome explicitly tries to guard against wrong client time and might not cooperate with your time tweaking either way, though.

//chromium/src/components/network_time/network_time_tracker.cc

// Network time queries are enabled on all desktop platforms except ChromeOS,
// which uses tlsdated to set the system time.

//chromium/src/components/ssl_errors/error_classification.cc

  if (now_system < build_time - base::TimeDelta::FromDays(2)) {
    build_time_state = CLOCK_STATE_PAST;
  } else if (now_system > build_time + base::TimeDelta::FromDays(365)) {
    build_time_state = CLOCK_STATE_FUTURE;
  }

Expired Certificates

Posted Sep 23, 2018 13:43 UTC (Sun) by rweikusat2 (subscriber, #117920) [Link] (3 responses)

There's no technical reason why one shouldn't trust an expired certificate. 'A certificate' is a public key plus some metainformation which both have been digitially signed utilizing some usually unrelated private key (if the private key corresponding to the public key in the certificate has been used, the certificate is said to be self-signed). The owner of the certificate will also have the secret private key corresponding with the public key and hence, someone who has access to the certificate can create messages only the certificate owner can decrypt. It's considered prudent to change encryption keys regular, that's why certificates "expire". But that's just encouraging a key change (which implies generating a new certificate) and doesn't enforce it: Unless the private key has been compromised, there's no need to stop using it.

Expired Certificates

Posted Sep 23, 2018 14:51 UTC (Sun) by Sesse (subscriber, #53779) [Link] (2 responses)

Other reasons why certificates expire include that the domain may have been transferred to another entity. And if somebody manages to generate a bad certificate somehow, one wants to limit the amount of damage that can be done.

Expired certificates are also generally not part of OSCP, so it's hard to revoke them in practice.

Expired Certificates

Posted Sep 23, 2018 16:57 UTC (Sun) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

A certificate as two time attributes called "not before" and "not after" which form the bounds of "certificate lifetime". That's a property of the certificate and has absolutely no relation to "domain ownership". In case of a domain changing owner, not that this would be applicable to the camera case, old certificates would probably be revoked, that is, put on a special "this certificate isn't considered valid anymore" list published by a CA (simplification).

'Bad certificates' would also usually be dealt with by revocation. Standard lifetime of commercial certificates is a year and "Oh well, the guy who pretends to be your bank in order to rob your account will be forced to stop next year!" wouldn't exactly be fit-for-purpose as security policy here.

Expired Certificates

Posted Sep 24, 2018 12:30 UTC (Mon) by KaiRo (subscriber, #1987) [Link]

One of the problems is that most certificate checks in software do not check revoking information, and even the sources for revoking information (CRLs, OCSP, etc.) have various issues, including privacy leaks and more. That's one reason why expiry has more weight than it should have in theory, because it puts a time limit on the issues around revocation.

Time namespaces

Posted Sep 24, 2018 14:49 UTC (Mon) by rriggs (guest, #11598) [Link]

The primary reason I would use time namespaces is to test code around DST changes, leap seconds, leap years, etc. It's rather difficult to mock that stuff because a lot of code acquires the time from system calls. I've done by overriding libc functions in an LD_PRELOADed library, but that doesn't provide the same coverage that changing the actual system time does.