Lighttpd

Hahaha. Your post made me laugh ... and then <sigh>

Sure, I'll look into some more defensive coding here and elsewhere in lighttpd, in case lighttpd finds itself mired in 1970.

Edit: see lighttpd git master branch for commit dbe3e236 and commit c035eb77 which prefers monotonic clock for various time references. (When I did that last week, times for session tickets were left using realtime since session tickets are communicated externally and lighttpd allows them to be configured from external sources.)

gstrauss wrote in #note-2:

Your patch looks like one viable option. Another is to initialize stek_rotate_ts to a negative value, e.g. -28800 or -86400 depending on the TLS module. That assumes that time_t is a signed value, which is generally true, but not guaranteed. I'll probably base a solution on your patch.

Yes, the fact that time_t can be either signed or unsigned makes it more complicated to find a simple solution.
I also though about casting cur_ts to something like uint64_t before substracting so that substracting something would make a big value.

I said that I wasn't sure about the patch because I didn't dig deep enough in the code to know if calling mod_openssl_session_ticket_key_generate() with the same values multiple time was an issue or not.
Because it could happen that cur_ts stays at zero all the time (broken time() implementation), which could work with the current code (function never called) but could cause issues if "0 == stek_rotate_ts" is added to the check as it would be called continuously.

If it is safe to call the function with the same parameters multiple times and everything is handled properly there, then I think it's a good patch.

I have a question for you: embedded devices do not tend to have a whole lot of entropy, and so it is considered good practice to save a random seed to persistent storage, and then to restore that random seed upon restart to reduce hangs waiting for initial entropy. Why is something similar not done with time? Why not ship the devices with a starting time of manufacturing time (and a random seed changed per device) for bootstrapping? Then the time might be weeks or months in the past, but would never be decades in the past (1970). Things might work better with TLS certificates, which have a better chance of being within a time window of validity. Things might also work better with cookies, HTTP Digest auth, etc.

Usually devices either have a RTC or use something like NTP to stay in time so the local date and time will still be good
But the RTC sometimes use a capacitor instead of a battery, which can be depleted in a few weeks if unplugged (instead of the few years of a typical RTC battery), and NTP needs the proper server which can be unavailable.

It would indeed be possible to store the time on shutdown (or at regular intervals as devices often don't have shutdown buttons but are often just unplugged), but depending on the shutdown duration the time could be off by a few minutes which could go unnoticed.

I think most software are often working just as fine in 1970 than with any other date, so there is usually no reason to implement something different.

Because it could happen that cur_ts stays at zero all the time (broken time() implementation), which could work with the current code (function never called) but could cause issues if "0 stek_rotate_ts" is added to the check as it would be called continuously.

Were time() to always return 0, that would not be a bug in lighttpd, but it might result in issues in lighttpd, such as application-level client idle timeout never triggering. Maintenance triggers -- including STEK rotation -- might never occur. So the (0 stek_rotate_ts) addition is fine.

Musing ... I am considering having lighttpd use int64_t (except when passing pointers) instead of time_t so that even 32-bit instances of lighttpd running on systems with 32-bit (signed) time_t are less susceptible to Y2038 issues. Then again, it sounds like some portion of those devices are stuck in 1970. :)

I think most software are often working just as fine in 1970 than with any other date, so there is usually no reason to implement something different.

<rant>
The scourge of the "internet of things" is ignoring security or treating security as unimportant. Among other things, TLS certificate validity is based on a shared notion of time, as are auth cookies and HTTP Digest auth nonces.
</rant>

Yes time() always returning 0 would be a major issue in the base system, I guess I might sometimes be doing defense programming a little bit too much !

I agree with you about IoT sometimes being very insecure, and it's hard for customers to know if devices are secure.

But even when you want to be implement it securely it can be complicated, time is not always easy to get and I don't think that there is a proper way to offer a https server with a valid certificate.

Which is probably why most IoT devices makes the internet connection mandatory (to get time from an online server and to receive commands from an online server) and you need to connect to an online server to configure the device that is on your LAN, which is not great either.