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

Going in circles without a real-time clock

rachelbythebay.com

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Going in circles without a real-time clock

#131

Post by hcfman »

lightswitch05 wrote: post #106
hcfman wrote: post #102

Earlier quoted context omitted.

Ah okay. Conversely I've never tried that setup :) Nice to hear about it though.

This is off-topic, but I was looking at your sbts-aru project and remembered having read the hackaday post on it about fireworks. I'm curious if you've ever seen the RaspberryShake BOOM sensor? If so, any thoughts on how your project and it differ? https://shop.raspberryshake.org/product/turnkey-iot-atmosphe...

If it syncs time accurately by any method maybe you are able to localize some very interesting events! The localization code I provide with my project should fine with times obtained from this project. I seriously doubt whether that project uses a memory overlayFS but it’s to add as an improvement.

Re: Going in circles without a real-time clock

#132

Post by raggi »

If you don't have an RTC I'd recommend having a tlsdate with some bounding heuristics to prevent extreme clock fixation from a mitm. You can relatively cheaply hit a large number of public servers that are likely to have good times available over TLS and trust the common result. You validate the certs without considering the notbefore stamps and then if you're feeling aggressive validate them after you've managed to approximate a date from the cohort. I know there are commercial packages that do this, I'm not sure about OSS ones.

Roughtime would be far better, but essentially there's no broad deployment of it yet.

Ideally something good would be picked by Raspbian and delivered in the distro as standard.

Re: Going in circles without a real-time clock

#133

Post by creeble »

jandrese wrote: post #108
creeble wrote: post #107

Earlier quoted context omitted.

You can use plain HTTP for time sync. Almost all HTTP servers respond with a time header.

The whole point of the exercise was to make it secure though. If you don't care about MITM attackers then NTP works great.

Isn't that a provably pointless exercise though?

Security protocols (at least the ones in common use) require certificates or keys that eventually expire, because of the risk of a permanent key being compromised. If they expire, the protocol needs time. QED.

Re: Going in circles without a real-time clock

#135

Post by shadowgovt »

Hrnrurj wrote: post #31
riobard wrote: post #14

Speaking of RTC battery, I've recently come to the realization that I have to make sure that BIOS battery is not absolutely dead in always-on PC boxes. Background: I use an x86 box as home router. I've changed the configuration in the BIOS that it should automatically boot up on power. However if the BIOS battery is dead, the config will be lost and it will revert to default settings, which is not to boot on power. B…

Voltage check on battery is part of regular PC maintenance. Like cleaning dust, checking all fans are spinning, capacitors are not getting bigger, checking for weird sounds in PSU, overnight memtest... You should do it every year or two...

Funny enough, instead of doing that every year, my policy has been "replace the machine if it breaks" and in general, I've gotten a good five-year cycle out of all my PCs without having to do disassemble-maintenance with an air can and a static strip. This has been good enough because I do enough high-graphics-demand gaming that five years is about the cycle on which some new-shiny has come out that renders my machine too old to play modern games.

Maybe I'm just lucky.

Re: Going in circles without a real-time clock

#136

Post by fuzzfactor »

dclowd9901 wrote: post #125

I’m not sure this is related or not but if there’s one thing I’ve learned about complex objects (engines, computers, software, sewing machines, etc), it’s that every _custom_ thing you do to it has some kind of order of magnitude impact on the overall complexity of the machine, and thus, you should avoid customizing it. At least if your primary concern is usability vs solving specific problems. It’s definitely served…

There is not much of an allowance any more for devices that are not on the internet 24/7 without fail.

Multi-booting PCs with Windows and Linux over the years, I have seen the time sync problem go from nonexistent to show-stopper.

For devices that you only need to connect to the internet occasionally or sporadically (so that's what you do), that's where I noticed it most.

Linux sets the RTC to UTC, then when you reboot to Windows, Windows uses the RTC as local time. Which for me is 5 or 6 hours different from UTC, depending on Daylight Savings Time.

Plus when Daylight Savings comes around, each OS wants to make a 1 hour correction the first time you boot it after that date. With multi-booting this can add up to more than one hour difference too.

Didn't used to be so bad, if you were a few hours (days or longer for many PCs) away from the actual time, things did not fail for this reason.

Eventually only one hour off was OK for a while, now nope.

There are just so many more obstacles to smooth reliable operation, and weak links in a more extensive chain that must remain perfectly strong. Otherwise the chain is broken, you are disconnected, and the weak link is too many sections away from you now to be within reach.

Complete perfection is required more so than ever, while at the same time, your efforts to approach perfection are being made more difficult.

Re: Going in circles without a real-time clock

#137

Post by growse »

mikepurvis wrote: post #54
mapreduce wrote: post #34

Earlier quoted context omitted.

> If you’re already trusting it for your IP address, you might as well trust it with the current UTC time I don't follow! How does trusting DHCP with IP address automatically mean I should trust it with the current UTC time? Time requires higher degree of trust than IP. I may not care what my IP address looks like but I might care a lot about what the current UTC time is and I might want this to come from a more trus…

DHCP servers can command your dns config and hostname too. It's not a total mitm story since the certs are still on the machine itself but it's definitely more than just a local IP address.

The don't really 'command' it, they 'suggest'. The client's free to ignore those suggestions :)

Re: Going in circles without a real-time clock

#138

Post by Dylan16807 »

gorkish wrote: post #128

The Pi ecosystem is coming apart at the seams. Talk about falling off a pedestal. By the time you buy everything you need to make a Pi 5 even remotely usable and reliable today, you'll have spent as much as a small form factor PC. What do you need? 1. Special power supply - Yes, it's USB-C but it requires a high amperage 5V supply instead of accepting a higher voltage like most USB-C stuff 2. Active cooler - Pi 5 thr…

The power supply is becoming less special over time. My first result for "usb c power supply" on amazon is a $25 anker 317 that supports PPS and will do 5 amps at any voltage. Not that that's an amazing price, but the feature is spreading.

But I agree that the price to get a happy Pi is pretty harsh compared to a tiny PC.

Re: Going in circles without a real-time clock

#139

Post by Dylan16807 »

cbhl wrote: post #118
smashed wrote: post #80

> I figured they must be running DNSSEC on that zone (or some part of it), and it must have a "not-before" constraint Since clients will attempt to resolve ntp.org in order to actually sync their clock, there is a good probability that some clients will be way off. Enabling dnssec on that zone was probably not without important drawbacks? I wonder if the operators thought about that potential pitfall. Seems like they…

If you _don't_ enable dnssec on ntp.org, then a mitm can intercept the dns request to redirect to an attacker-owned timeserver with a time in the past. Then the host can have old and expired (without loss of generality) keys/certificates replayed against it. If memory serves though, Raspbian used to not even have `fake-hwclock` by default and even more Pis would end up with this "wildly wrong time near the epoch and…

> If you _don't_ enable dnssec on ntp.org, then a mitm can intercept the dns request to redirect to an attacker-owned timeserver with a time in the past. Then the host can have old and expired (without loss of generality) keys/certificates replayed against it.

Preventing DNS mitm only matters if you prevent NTP mitm too.

What percent of NTP clients talking to these servers are doing it in a secure way? And is that share growing?

Re: Going in circles without a real-time clock

#140

Post by duskwuff »

mkesper wrote: post #47
qiqitori wrote: post #17

Earlier quoted context omitted.

Some unsolicited solutions, maybe not for you but somebody in a similar situation: maybe replace it with a supercapacitor (needs some wiring changes, otherwise it won't ever be charged, should last long enough for most power outages), or use a stack of coin cells in parallel (difficult due to physical dimensions, and they'll still go dead at some point). You can also short two wires on the ATX supply to automatically…

If using supercapacitors, use some known not for leaking else you're back to square one (do a search for capacitor recap).

That issue doesn't apply to supercapacitors (nor to any capacitor manufactured in the last 15-20 years, really). It affected some aluminum electrolytic capacitors manufactured with a defective electrolyte in the early 2000s.
Post reply on HN