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

More Memory Safety for Let's Encrypt: Deploying ntpd-rs

letsencrypt.org

Post reply on HN
Print view View original

151–160 of 177 posts

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#151

Post by IshKebab »

xorcist wrote: post #140
IshKebab wrote: post #136

Earlier quoted context omitted.

That config file perfectly illustrates the point. There's no need for it to be custom, and require me to waste time learning its syntax when it could just be JSON or TOML. Honestly I would even take YAML over that and YAML is the worst.

You still have to learn the syntax even if it is expressed in json or yaml. Perhaps stating the obvious, but not every json object is a valid ntp configuration. The configuration object will always and by definition be proprietary to ntp. Expressing it as plain text allows for a trivial parser, without any of the security implications of wrapping it in a general language language ("should this string be escaped?", "w…

Sure you have to learn how to configure things but you don't have to learn basic syntax like "how do I escape a string".

The fact that it has survived tells you nothing other than it's not so completely awful that someone went through the pain of fixing it. That doesn't mean it is good. There are plenty of awful things that survive because replacing them is painful due to network effects. Bash for example.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#152

Post by dfc »

rnijveld wrote: post #119
syncsynchalt wrote: post #25

Earlier quoted context omitted.

The biggest danger in NTP isn't memory safety (though good on this project for tackling it), it's (a) the inherent risks in implementing a protocol based on trivially spoofable UDP that can be used to do amplification and reflection and (b) emergent resonant behavior from your implementation that will inadvertently DDOS critical infrastructure when all 100m installed copies of your daemon decide to send a packet to N…

I agree that amplification and reflection definitely are worries, which is why we are working towards NTS becoming a default on the internet. NTS would prevent responses by a server from a spoofed packet and at the same time would make sure that NTP clients can finally start trusting their time instead of hoping that there are no malicious actors anywhere near them. You can read about it on our blog as well: https://…

> I cannot imagine NTP responses being much bigger than two or three times their related request.

I think you must be limiting your imagination to ntp requests related to setting the time. There are a lot of other commands in the protocol used for management and metrics. The `monlist` command was good for 200x amplification. https://blog.cloudflare.com/understanding-and-mitigating-ntp...

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#153

Post by rnijveld »

dfc wrote: post #152
rnijveld wrote: post #119

Earlier quoted context omitted.

I agree that amplification and reflection definitely are worries, which is why we are working towards NTS becoming a default on the internet. NTS would prevent responses by a server from a spoofed packet and at the same time would make sure that NTP clients can finally start trusting their time instead of hoping that there are no malicious actors anywhere near them. You can read about it on our blog as well: https://…

> I cannot imagine NTP responses being much bigger than two or three times their related request. I think you must be limiting your imagination to ntp requests related to setting the time. There are a lot of other commands in the protocol used for management and metrics. The `monlist` command was good for 200x amplification. https://blog.cloudflare.com/understanding-and-mitigating-ntp...

Ah right! I always forget about that since we don’t implement the management protocol in ntpd-rs. I think it’s insane that stuff should go over the same socket as the normal time messages. Something I don’t ever see us implementing.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#154

Post by stouset »

maxbond wrote: post #95
landmarker11 wrote: post #69

Earlier quoted context omitted.

[dead]

That's a bummer honestly, I would encourage you not to let Internet flamewars color your decisions about what languages you might learn. The well is seriously poisoned with regards to Rust in this community. That's more of a reflection on HN than the value of Rust as a technology or even the Rust community. Don't learn Rust if you aren't interested, it's not a one true language, but don't cheat yourself on engaging w…

HN is capable of discussing it just fine. Low-effort, bad faith posts getting downvoted into oblivion is the system working as intended.

GP is obstinately failing to grasp the difference between “can” and “should”. Networked services can be securely written in C. Networked services should not be written in C.

There are people who can operate motor vehicles safely at speeds regularly in excess of 100mph. People should not do so on public roads.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#156

Post by astrobe_ »

cogman10 wrote: post #28

This seems like a weird place to be touting memory safety. It's ntpd, it doesn't seem like a place for any sort of attack vector and it's been running on many VMs without exploding memory for a while now. I'd think there are far more critical components to rewrite in a memory safe language than the clock synchronizer.

Agreed. It is a "good old" binary protocol, so the many gotchas of text protocols are not there.

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#157

Post by yjftsjthsd-h »

xorcist wrote: post #139
hi-v-rocknroll wrote: post #114

Earlier quoted context omitted.

You might be doing too much work at the wrong level of abstraction. VMs should use host clock synchronization. It requires some work and coordination, but it eliminates the need for ntp in VMs entirely. Hosts should then be synced using PTP or a proper NTP local stratum (just get a proper GNSS source for each DC if you have then funds). https://tsn.readthedocs.io/timesync.html Deploy chrony to bare metal servers wher…

This makes sense. The clock is just another piece of hardware to be virtualized and shared among the guests. But last time I said that with some pretense of authority, someone shoved me a whitepaper from VMware that said the opposite. Best practice was stated be to sync each guest individually with a completely virtual clock. I'm not sure I agree, but at least I try to be open to be possibility that there are situati…

> a whitepaper from VMware that said the opposite

Did it say why?

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#158

Post by asdask »

stouset wrote: post #154
maxbond wrote: post #95

Earlier quoted context omitted.

That's a bummer honestly, I would encourage you not to let Internet flamewars color your decisions about what languages you might learn. The well is seriously poisoned with regards to Rust in this community. That's more of a reflection on HN than the value of Rust as a technology or even the Rust community. Don't learn Rust if you aren't interested, it's not a one true language, but don't cheat yourself on engaging w…

HN is capable of discussing it just fine. Low-effort, bad faith posts getting downvoted into oblivion is the system working as intended. GP is obstinately failing to grasp the difference between “can” and “should”. Networked services can be securely written in C. Networked services should not be written in C. There are people who can operate motor vehicles safely at speeds regularly in excess of 100mph. People should…

[flagged]

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#159

Post by yosefk »

quectophoton wrote: post #149
pjmlp wrote: post #121

Earlier quoted context omitted.

I would consider that serious attempts have been made since 1961, however all of them failed in the presence of a free beer OS, with free beer unsafe compilers. The getting traction part is the relevance part.

Yeah, all previous attempts at making such a language lacked two things: 1. They didn't have a big, well-known, company name with good enough reputation to attract contributors. 2. They didn't have brackets. Success was because traction, traction was because appeal, and appeal was mostly because those two things. Nothing else was new AFAIK.

No shared mutable state in an imperative language is common, as are memory safe languages with performance close to C's? Didn't see the latter in the language shootout benchmarks, in fact Rust is much closer to C than the next closest thing

Re: More Memory Safety for Let's Encrypt: Deploying ntpd-rs

#160

Post by twothreeone »

vmfunction wrote: post #133
twothreeone wrote: post #47

Earlier quoted context omitted.

It continues to astonish me how little people care (i.e., it triggers the $%&@ out of me). I really appreciate the professionalism and cool rationale when faced with absolute ignorance of how shaky a foundation our "modern" software stack is built upon. This is a huge service to the community, kudos to you and many others slowly grinding out progress!

Lol, shaky indeed. A business person once said, "can you imagine if machine engineer (like auto makers) behave like software engineering?". Seems no digital system is truly secure. Moving foundational code to memory safe seems like a good first step.

That's because there is no such thing as "truly secure", there can only be "secure under an assumed threat model, where the attacker has these specific capabilities: ...". I agree that software engineering is getting away with chaos and insanity compared to civil or other engineering practices, which have to obey the laws of physics.
Post reply on HN