Re: Raspberry Pi startup: certificate is not yet valid
Yo Hal! On Wed, 11 May 2022 01:53:30 -0700 Hal Murray wrote: > > I like you suggestion of ntpd using "-g" to get the system time > > close, before checking any certificates. > > It was Richard's suggestion, not mine. The idea was to only skip the > date checks and do the rest of the certificate checking. You can see how well I'm paying attention > The main reason is that it's a hole in securty. I don't want to > clutter up security discussions and documentation with that very > unlikely case. It could be a non-default option, coupled with serious warnings. > The second reason is that OpenSSL isn't setup to skip only the date > check. We could easily implement your version of no-check, but that > would make the tiny security hole a big hole. I find that convincing. If OpenSSL does not have the knob, game over. > I think the alternative is to get the clock reasonably close before > running ntpd. And the traditional solution(s). > What is swclock? What distros does it run on? swlock is part of OpenRC. Which is in any OS that runs OpenRC, like Gentoo. On startup it resets the system time to the time of the last shutdown (usually). https://github.com/openrc/openrc/ > I think the Linux kernel sets the clock to the build time or > something similar. Nope. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpOJGMK60W31.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
On Wednesday, May 11, 2022, 03:31:52 AM PDT, Hal Murray via devel wrote: > Thanks. > > I like you suggestion of ntpd using "-g" to get the system time close, >before > > checking any certificates. > It was Richard's suggestion, not mine. The idea was to only skip the date checks and do the rest of the certificate checking. > I don't like it for 2 reasons. > The main reason is that it's a hole in securty. I don't want to clutter up security discussions and documentation with that very unlikely case. > The second reason is that OpenSSL isn't setup to skip only the date check. >We could easily implement your version of no-check, but that would make the tiny security hole a big hole. > -- > I think the alternative is to get the clock reasonably close before running ntpd. > PCs with RTC/CMOS/TOY clocks are simple. We will have to document potential troubles wtih dead batteries. > The problem is with Raspberry Pis and similar low-end systems that don't have a hardware clock. > As far as I can tell, each distro does it differently. So we will have to document what to do on each distro. > > The problem I see a lot is that a lot of Pi's are started with no network > > connection, and a bad time, so swclock is commonly used before starting >ntpd. > What is swclock? What distros does it run on? > I think the Linux kernel sets the clock to the build time or something >similar. > Debian/Ubuntu have fake-hwclock. It updates the time in a file on halt and every hour so you have decent restart time on boot after a crash. It's "just" a shell script so it should be easy to copy to other distros. > I haven't found anything for Fedora. > I haven't looked for FreeBSD or NetBSD. swclock is a C program (source is at https://github.com/OpenRC/openrc under src/swclock) and it doesn't quite run the same way. swclock claims to use the mtime of a file while fake-hwclock seems to use the contents of a different file. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
Thanks. > I like you suggestion of ntpd using "-g" to get the system time close, before > checking any certificates. It was Richard's suggestion, not mine. The idea was to only skip the date checks and do the rest of the certificate checking. I don't like it for 2 reasons. The main reason is that it's a hole in securty. I don't want to clutter up security discussions and documentation with that very unlikely case. The second reason is that OpenSSL isn't setup to skip only the date check. We could easily implement your version of no-check, but that would make the tiny security hole a big hole. -- I think the alternative is to get the clock reasonably close before running ntpd. PCs with RTC/CMOS/TOY clocks are simple. We will have to document potential troubles wtih dead batteries. The problem is with Raspberry Pis and similar low-end systems that don't have a hardware clock. As far as I can tell, each distro does it differently. So we will have to document what to do on each distro. > The problem I see a lot is that a lot of Pi's are started with no network > connection, and a bad time, so swclock is commonly used before starting ntpd. What is swclock? What distros does it run on? I think the Linux kernel sets the clock to the build time or something similar. Debian/Ubuntu have fake-hwclock. It updates the time in a file on halt and every hour so you have decent restart time on boot after a crash. It's "just" a shell script so it should be easy to copy to other distros. I haven't found anything for Fedora. I haven't looked for FreeBSD or NetBSD. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
Yo Hal! On Tue, 10 May 2022 10:26:08 -0700 Hal Murray wrote: > Gary said: > >> Should we do something like set the time to the time stamp of the > >> drift file? (if it is significantly newer than the current time) > > > Nope. Don't get in a fight with the OS. > > Could you please say more. Be careful whjat you ask for. > The whole purpose of ntpsec is to keep good time. Yes, but so many other tasks also may think that is their job. When two fight, bad things happen. It is the job of the OS, using it RC method (OpenRC, systemd(umb), launchd, etc.) to pick the right programs, in the right order, to keep time on that host. > If we know the > clock is way off, what's wrong with taking a big step to get a lot > closer so certificate checking has a better chance of working? Nothing at all, once the system RC has tol ntpsec that system time is its job, then ntpsec needs to do the best job it can. I like you suggestion of ntpd using "-g" to get the system time close, before checking any certificates. The problem I see a lot is that a lot of Pi's are started with no network connection, and a bad time, so swclock is commonly used before starting ntpd. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpedRM2Q6rfa.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
Gary said: >> Should we do something like set the time to the time stamp of the >> drift file? (if it is significantly newer than the current time) > Nope. Don't get in a fight with the OS. Could you please say more. The whole purpose of ntpsec is to keep good time. If we know the clock is way off, what's wrong with taking a big step to get a lot closer so certificate checking has a better chance of working? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
Yo Hal! On Mon, 09 May 2022 00:38:34 -0700 Hal Murray via devel wrote: > Does anybody know how the initial time gets set on a Raspberry Pi -- > before ntpd gets called? It depends. Some use swclock, some use ntpclient, some use an RTC, some use a GNSS time. > I have a recently setup system that gets initialized to 2022-04-01 > and is trying to use a certificate that was created after that. :) Fun. > Should we do something like set the time to the time stamp of the > drift file? (if it is significantly newer than the current time) Nope. Don't get in a fight with the OS. > Do we have a document that collects interesting things about NTS and > certificates? Nope. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin pgpsrXzIZzJIE.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
Richard Laager said: > I believe you're looking for "fake-hwclock". It periodically saves the time > to a file (allegedly* /etc/fake-hwclock.data) and restores it on boot. Thanks. I discovered fake-hwclock via Google but it wasn't on my system and the discussion I was looking at was very old so I assumed it had been replaced or something. Looks like Ubuntu just didn't include it in their img file that I used. I installed it and things are happy. I think this is a good-enough solution. Basically, we have to document that the clock has to be close-enough and what close-enough means. Cold-stanbys sitting on the shelf for many years won't work. PCs with dead CMOS/TOY clock battries won't work. (Let's Encrypt certificates are only valid for 90 days.) IoT devices on a store shelf for a few months might not work. Working Raspberry PIs that sit on the shelf for long enough may not work. You can fix the stanby/store shelf problem by carefully setting up certificates with a long lifetime. -- > I still think we need a more comprehensive approach to this bootstrapping > problem. The problem is, I don't have the time to write it. But I gave my > thoughts before: https://lists.ntpsec.org/pipermail/devel/2019-February/ > 007576.html That looks reasonable, but complicated. I'm not planning to work on anything like that. -- >> That could backfire if, somehow, the system time got set into the future. >I had that happen once. It might have been due to a GPS rollover. GPS rollover seems more likely to go the other way -- that is step back by 20 years. It would go forwards if it was broken, you used fudge to fix it, and then the software got fixed and you installed the new software without removing the fudge. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Raspberry Pi startup: certificate is not yet valid
On 5/9/22 02:38, Hal Murray via devel wrote: Does anybody know how the initial time gets set on a Raspberry Pi -- before ntpd gets called? I believe you're looking for "fake-hwclock". It periodically saves the time to a file (allegedly* /etc/fake-hwclock.data) and restores it on boot. * My home pi died, so I can't immediately double-check this. Should we do something like set the time to the time stamp of the drift file? (if it is significantly newer than the current time) Probably not. I still think we need a more comprehensive approach to this bootstrapping problem. The problem is, I don't have the time to write it. But I gave my thoughts before: https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html The only update I have is that this statement is not true: "A normal CA will not issue certificates that are valid longer than their root". Let's Encrypt is serving a chain to the expired DST Root for enhanced compatibility with old Android devices. That could backfire if, somehow, the system time got set into the future. I had that happen once. It might have been due to a GPS rollover. -- Richard OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Raspberry Pi startup: certificate is not yet valid
Does anybody know how the initial time gets set on a Raspberry Pi -- before ntpd gets called? I have a recently setup system that gets initialized to 2022-04-01 and is trying to use a certificate that was created after that. :) Should we do something like set the time to the time stamp of the drift file? (if it is significantly newer than the current time) That could backfire if, somehow, the system time got set into the future. A variation on this would be a system sitting on a shelf for a long time. Do we have a document that collects interesting things about NTS and certificates? -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
