RusTLS Formal Audit [pdf] | Hacker News Reader

RusTLS Formal Audit [pdf]

github.com

156 pointsdralley25 comments

It seems kind of strange that they don't reference specific commits (and instead just point to master?) in the report. Isn't it standard to analyze like, a specific release?

They do, they mention it in the third paragraph of the introduction.

The only version mentioned in that paragraph is 'version 0.16 or newer' of rustls, which is only one of the packages they looked at, but it doesn't specify any specific releases or commits that were actually looked at.

I'm curious when/if there will be a drive to displace OpenSSL with RusTLS. I'm also unsure how many remote exploits have come down to TLS implementations, but it seems that it's such a core part of system security, any drive towards providing a library more safe from exploit is a good goal. Also, would be interesting to see performance differences.

Perhaps an entry point could be this project https://github.com/mesalock-linux/mesalink that provides an openssl-compatible interface for rustls.

I don't have first hand experience of this, but I have read several things suggesting that a big part of the problem with OpenSSL is the API - that it doesn't help you to make sensible security decisions. A large part of the design of RusTLS seems to be to have sensible defaults and to not make available insecure algorithms.

That said, we shouldn't let perfect be the enemy of good. An OpenSSL compatible implementation with no memory issues would definitely be good.

Yes. One of the main problem of OpenSSL is how messy is the API itself.

There is a pretty good talk about it by the libreSSL guys on that [1]

[1]: https://www.youtube.com/watch?v=Wd_dyRbE4AA

I don't think it will be used any time soon by something major, the fact that it only supports TLS1.2 and TLS1.3 is a problem for lot of use cases. Also because it's more secure than OpenSSL is just one thing, what about bugs? OpenSSL is battle tested and widely used.

The vast majority of important OpenSSL bugs _are_ security bugs, no?

There are more than a few OpenSSL alternatives. RusTLS is probably not in the lead, not as long as people don't introduce Rust into the base system or their build.

If the Rust displaces C/C++, that introduction could be viewed as an advantage.

> not as long as people don't introduce Rust into the base system

If your base system uses Firefox or ripgrep, Rust is already there.

'Already there' in that case is just 'there's a package for Rust and cargo' (but not necessarily RusTLS). That still leaves a significant integration challenge.

Most (all?) Linux distros (Debian, Arch, Ubuntu, Fedora, ...) use their packaged Rust and cargo to build other packages like Firefox, ripgrep, etc.

Which challenges are not showing up there ? There are packages, and they are usable to build other packages.

1) "I'm using Python/Ruby/Java/C#/some other non-C/C++/Rust language, how do I even call this RusTLS thingy? OpenSSL has shims everywhere so I don't have to worry about FFI/JNI/etc."

2) "My distro does not include a RusTLS package. How do I package this? Do I have to add Rust to my build dependencies now? How do I add the Rust steps to my build system? Where was that CMake manual again..."

Rust has a bright future ahead, but yet another TLS library doesn't justify the overhead and complexity of bringing Rust into a build of non-Rust code. Now, if most distros were to offer a rustls package, this could be entirely different story.

Firefox isn’t exactly fair to include; it has a notoriously complicated build system. Supporting a Firefox build doesn’t necessarily mean that one has general support for Rust.

Sure, but which distro does not package Rust and use the packaged Rust to build Firefox ?

Debian, Ubuntu, Fedora, Arch, ... all do this.

Some more discussion earlier today: https://news.ycombinator.com/item?id=23520004

It's now vetted by CryptoCat's author so it must be good.

At least if you somewhat trust the reviewer we now know that it has no glaring problems and seems to be well designed.

Which is important because without any external reviews how would we know if it wasn't written by some people with "dangerous" skill levels being high enough to look good for someone having no idea about TLS but to low to actually get it right. I do have seen some open source projects over the years where that was the case and the authors where not open for any form of critique, which lead to situations where you seemed to get a high quality well maintained library but you got a somewhat high quality well maintained library with hidden extremely dangerous bugs the authors have no intention of fixing and closing all issues about them...

Nice to hear that Rustls is not such a bad apple but a most likely good pice of work.

> At least if you somewhat trust the reviewer we now know that it has no glaring problems and seems to be well designed.

I believe OP was making fun of the review. Cryptocat was full of questionable choices (https://tobtu.com/decryptocat.php) as well as widely disputed security claims.

Exactly, Nadim Kobeissi's name is the last one I expected to see on a crypto audit that someone would pay for. Internet never completely forgets, but in practice a little with your head down and your past sins wash out.

He went a really long way since 2013 and his debuts with CryptoCat : he got a PhD in one of the top European crypto research team, on formal verification of crypto implementations.

I would confidently guess that's way more legitimate that any opinion you could formulate against this audit, based on ad hominem attacks.

He completely rewrote CryptoCat in 2016 and that still wasn't good, the security page was at https://web.archive.org/web/20160407125207/https://crypto.ca... and there were still pretty bad issues, notably the file sharing disclosing the exact size of the file shared, despite him stating "Cryptocat makes the following assumptions: Untrusted network: We assume that an attacker controls the network and so can intercept, tamper with and inject network messages.".

This was not "ECDH completely broken" bad, by far, but still far from good. I guess that was still before obtaining his PhD.

And about not liking the guy, I'll admit reading https://www.courtlistener.com/docket/14868600/todd-v-reichwe... biased me...

The point is that I absolutely don't trust one of them, but I guess the reference was too obscure for most.

Reply on news.ycombinator.com