Live data from Hacker News

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

letsencrypt.org

161–170 of 177 posts

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

#161
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.

I take a slightly different view of this, though I do not deny that those things are important. #1 in particular was important to my early involvement in Rust, though I had also tinkered with several other "C replacement" languages in the past.

A lot of them simply assumed that some amount of "overhead," vaguely described, was acceptable to the target audience. Either tracing GC or reference counting. "but we're kinda close to C performance" was a thing that was said, but wasn't really actually true. Or rather, it was true in a different sense: as computers got faster, more application domains could deal with some overhead, and so the true domain of "low level programming languages" shrunk. And so finally, Rust came along, being able to tackle the true "last mile" for memory unsafety.

Rust even almost missed the boat on this up until as late as one year before Rust 1.0! We would have gotten closer than most if RFC 230 hadn't landed, but in retrospect this decision was absolutely pivotal for Rust to rise to the degree that it has.

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

#162

Earlier quoted context omitted.

I hadn't heard of NTS until a Debian upgrade quietly installed ntpsec. It seems to now be the Debian default.

ntp has been replaced by ntpsec in Debian. (I am the Debian ntpsec package maintainer.) By default, NTPsec on Debian uses the NTP Pool, so no NTS. But NTPsec does support NTS if you are running your own server and supports it opt-in on the client side. As far as I know, the Debian “default” is systemd-timesyncd. That is what you get out of the box. (Though, honestly, I automate most of my Linux installs, so I don’t i…

Ah not quite, I think pooling would be rather easier than you've thought, there are Let's Encrypt people here, but let me explain what you'd do to have N unrelated machines which are all able to successfully claim they are some-shared-name.example

Each such machine mints (as often as it wants, but at least once) a document called a Certificate Signing Request. This is a signed (thus cannot be forged) document but it's public (so it needn't be confidential) and it basically says "Here's my public key, I claim I am some-shared-name.example, and I've signed this document with my private key so you can tell it was me who made it".

The centralized service collects these public documents for legitimate members of the pool and it asks a CA to issue certificates for them. The CA wants a CSR, that's literally what it asks for -- Let's Encrypt clients actually just make one for you automatically, they still need one. Then the certificates are likewise public documents and can be just provided to anybody who wants them (including the NTP pool servers they're actually for which can collect a current certificate periodically).

So you're only moving two public, signed, documents, which isn't hard to get right, you should indeed probably do this out-of-band but you aren't sharing the valuable private key anywhere, that's a terrible idea as well as being hard to do correctly it's just unnecessary.

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

#163
post #123

Earlier quoted context omitted.

Golang's error handling is safer than C's, but it's more cumbersome than it needs to be. In high-level code, nearly every func you write can return an error, and 99% of the time you're just going to pass the error up. Webserver will catch all and send 4xx or 5xx, for example. Exceptions are a lot more convenient and encourage solid error handling. Rust chose a good in-between (the "?" unwrapping syntax). In mid or lo…

Every now and then I think about forking Go and adding something like ?, and Pascal/Modula-2 like enumerations. However then I realise, why bother, and go back into using C#, Java, D instead.

The only thing I seriously plan to use Golang for is implementing a scripting language in my spare time. Its threading model (greenthreads flexibly mapped to OS threads) is attractive for that.

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

#164

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://…

Thank you for your considered response!

I hadn't heard about NTS and I'm rolling it out to my fleet of timeservers now.

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

#165
post #102

Earlier quoted context omitted.

Poorly thought out, ad-hoc homegrown config file format, please. Every time. 1. Code doesn't change at the whims of others. 2. The entire parser for an INI-style config can be in about 20 lines of C 3. Attacker doesn't also get to exploit code you've never read in the third party dependency (and its dependencies! The JSON dependency now wants to pull in the ICU library... I guess you're linking to that, too) 4. Compl…

I feel like using the incomprehensibly error-prone and inscrutable sudoers format as an example kinda argues against your point. (I do agree that JSON is a terrible configuration file format, though.)

My argument was not that sudoers is good - it's crazy overcomplicated.

My argument was data interchange format standards are orthogonal to config files. They don't have the same goals.

A programmer who thinks "I'll use JSON|YAML|TOML for my config file" - well, you didn't solve your first problem (what should the config look like, in a way that makes sense and is easily readable, understandable, updateable by the user) and you added a second problem before you even started solving the first - whatever your config looks like, it now also has to be 100% compliant with some data interchange format and support all its features, and that's going to require a lot of code - and then we get into whether you write the compliant parser/generator, or if someone else does and you do/don't audit every line of it. And then on top of that you add an additional pile of code to parse/generate whatever your actual config format is.

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

#166

Unlike say, coreutils, ntp is something very far from being a solved problem and the memory safety of the solution is unfortunately going to play second fiddle to its efficacy. For example, we only use chrony because it’s so much better than whatever came with your system (especially on virtual machines). ntpd-rs would have to come at least within spitting distance of chrony’s time keeping abilities to even be up for…

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…

We've had issues relying on ESXi host/guest time synchronization, depending on the guest OS, and found this to be a better solution.

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

#167

Earlier quoted context omitted.

I hadn't heard of NTS until a Debian upgrade quietly installed ntpsec. It seems to now be the Debian default.

ntp has been replaced by ntpsec in Debian. (I am the Debian ntpsec package maintainer.) By default, NTPsec on Debian uses the NTP Pool, so no NTS. But NTPsec does support NTS if you are running your own server and supports it opt-in on the client side. As far as I know, the Debian “default” is systemd-timesyncd. That is what you get out of the box. (Though, honestly, I automate most of my Linux installs, so I don’t i…

Thanks - "ntp has been replaced ntpsec", but it's not the default. My mistake - my systems are systemd-free.

On my initial encounter with ntpsec, I found ntpsec running, but ntp was also installed. That's an interesting construction of "replace". This would be hard to replicate, because I don't know when ntpsec turned up; otherwise I'd try to make a bug report. If ntpsec was replacing ntp, I'd expect to find no ntp after the update.

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

#168

Earlier quoted context omitted.

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.

Remind me of the One World Trade Center rebuild, and "if you want a 747-proof building, you're building a bunker".

Translate the internet to the real world, and basically every building (IP address) is getting shot at, hit by planes, nuked, bioweapons are stuffed into the mail slot, and lock-picked all day, every day.

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

#169

Earlier quoted context omitted.

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.

I take a slightly different view of this, though I do not deny that those things are important. #1 in particular was important to my early involvement in Rust, though I had also tinkered with several other "C replacement" languages in the past. A lot of them simply assumed that some amount of "overhead," vaguely described, was acceptable to the target audience. Either tracing GC or reference counting. "but we're kind…

That wasn't the case of Modula-2, Ada or Object Pascal.

Their problems was a mix of not being hieroglyph languages (too much text to type!), being much strongly typed (straitjacket programming with a famous rant post, wrongly), commercial offerings being expensive (more so against free in the box alternative), and not comming with an OS to make their use unavoidable.

Note that for all the hype, Zig is basically Modula-2 features with C syntax, to certain extent.

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

#170
post #169

Earlier quoted context omitted.

I take a slightly different view of this, though I do not deny that those things are important. #1 in particular was important to my early involvement in Rust, though I had also tinkered with several other "C replacement" languages in the past. A lot of them simply assumed that some amount of "overhead," vaguely described, was acceptable to the target audience. Either tracing GC or reference counting. "but we're kind…

That wasn't the case of Modula-2, Ada or Object Pascal. Their problems was a mix of not being hieroglyph languages (too much text to type!), being much strongly typed (straitjacket programming with a famous rant post, wrongly), commercial offerings being expensive (more so against free in the box alternative), and not comming with an OS to make their use unavoidable. Note that for all the hype, Zig is basically Modul…

> not comming with an OS to make their use unavoidable.

Early MacOS did use Pascal, though IIRC not Object Pascal.

Post reply on HN