TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

You Can't Trust Network Time

58 点作者 dominicl大约 6 年前

13 条评论

CaliforniaKarl大约 6 年前
DHCP already has support for providing an NTP server IP; there has been at least one proposal[1] to also provide a DHCP option specifying the &quot;rough current time&quot;, so that devices have at least _something_ to start with. As for trust, you&#x27;re already going to be trusting DHCP to give you an IP address, you could also trust it for this (with some safeguard in place to catch known-wrong values).<p>This kindof reinforces how having an &#x27;IoT Gateway&#x27; would be a good idea: The gateway can provide DHCP, and rough time, and (S)NTP, and DNS, and can also act as a proxy to the outside.<p>[1]: <a href="http:&#x2F;&#x2F;www.potaroo.net&#x2F;ietf&#x2F;idref&#x2F;draft-ogud-dhc-udp-time-option&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.potaroo.net&#x2F;ietf&#x2F;idref&#x2F;draft-ogud-dhc-udp-time-op...</a>
评论 #19773179 未加载
评论 #19774555 未加载
评论 #19774403 未加载
评论 #19773780 未加载
mindslight大约 6 年前
Articles that go around in circles while avoiding reflection or synthesis are infuriating. Of course relying on the PKI isn&#x27;t going to magically solve every problem. But the article wasn&#x27;t titled &quot;Why you can&#x27;t trust the PKI&quot;, because we&#x27;re all bored of reading about that.<p>At a certain point, you <i>must</i> choose some <i>immutable</i> trust root. If your kink is to use public CAs (fuck me harder, (go)daddy), it implies attacks. If you chose to setup your own private signing key, it implies attacks. If you choose longest sha256 chain (&quot;blockchain&quot;), it implies attacks. If you simply stop trying to retain absolute control over devices after they&#x27;re owned by someone else, it implies attacks.<p>You can hardcode further constraints as mitigations, but the fundamental drawbacks remain. If you want direct synthesis from the immediate complaint, keep a bit of a state to ensure that the date only ever moves monotonically forward. However you&#x27;ll still be open to an attack if the device is off while a certificate is compromised.
xyzzy_plugh大约 6 年前
This is a genuine problem across a variety of platforms, not just IoT. There really is no great way to &quot;solve&quot; for trust when one party might have extremely stale information. Awareness of this problem is surprisingly poor.<p>&gt; In the next blog post of this series we want to introduce a new secure network time protocol based on blockchain technology and show how even the smallest devices can establish completely secure connections.<p>This is a pretty disappointing way to end the article. Most &quot;solutions&quot; end up being some form of obfuscation, I&#x27;d guess this is too.
评论 #19773397 未加载
TheRealPomax大约 6 年前
There is only a catch-22 if we need _that time source_ to verify its time.<p>That&#x27;s not how things work, though: we have hundreds available, so there is no catch-22 whatsoever: we check multiple sources and go with the majority vote, then flag an error for any outlier(s).
评论 #19774020 未加载
评论 #19774078 未加载
adontz大约 6 年前
If we can&#x27;t get precise time securely and do not have real-time clock, it does not mean, there are no options left.<p>For instance, device may be booted for the first time in secure controlled environment and synchronize time fro trusted source.<p>Then, every N seconds (like 60 to 3600), device will write current time to local file. Most devices have some kind of writable local storage.<p>Any next synchronization will not be able to return time before already experienced moment. Certificate expiration will actually work, with a bit higher tolerance of a few hours.
becauseiam大约 6 年前
Adam Langley&#x27;s Roughtime protocol[1] largely solves some (but not all types) of time malfeasance, and a variant of it is already an IETF draft specification[2]. There is also NTS, which is secure NTP and provides some protections, but not nearly as many.<p>[1]: <a href="https:&#x2F;&#x2F;roughtime.googlesource.com&#x2F;roughtime&#x2F;" rel="nofollow">https:&#x2F;&#x2F;roughtime.googlesource.com&#x2F;roughtime&#x2F;</a><p>[2]: <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-roughtime-aanchal-01" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-roughtime-aanchal-01</a>
k_sze大约 6 年前
An (interesting, but impractical) solution to this problem would be to use astronomy to deduce the current date first, which should be good enough to validate the certificate.<p>See this QA on Astronomy StackExchange: <a href="https:&#x2F;&#x2F;astronomy.stackexchange.com&#x2F;questions&#x2F;12886&#x2F;get-date-and-time-by-position-of-the-sun-and-the-observer-position" rel="nofollow">https:&#x2F;&#x2F;astronomy.stackexchange.com&#x2F;questions&#x2F;12886&#x2F;get-date...</a>
exabrial大约 6 年前
One could pin a cert, hope the device is powered on in the validity period to update it? Obviously a bad idea for other reasons but maybe it&#x27;s the best worst choice.
yjftsjthsd-h大约 6 年前
Maybe dumb, but... Why not just make ntpd actually check certificate revocation? Easier than fixing everything that uses HTTPS, and seems to fix it?
评论 #19772085 未加载
评论 #19773280 未加载
评论 #19772023 未加载
zamadatix大约 6 年前
Assuming something in the trusted side of the network chain has a persistent clock or verified time then this issue could be avoided. For things that connect directly to untrusted networks e.g. public cellular internet the only solution I can see is using devices with a persistent clock themselves.
imglorp大约 6 年前
IETF working group - <a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-ietf-ntp-network-time-security&#x2F;" rel="nofollow">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;draft-ietf-ntp-network-time...</a>
noja大约 6 年前
So ignore the time on the cert? Isn&#x27;t that better than having no cert?
评论 #19772848 未加载
sverige大约 6 年前
I&#x27;m probably the only one who thinks it&#x27;s really stupid to connect things like refrigerators and washing machines to the internet, but I&#x27;m going to say it anyway.
评论 #19772970 未加载
评论 #19772923 未加载
评论 #19774724 未加载
评论 #19774511 未加载
评论 #19774545 未加载
评论 #19773682 未加载