
RusTLS Formal Audit [pdf] - dralley
https://github.com/ctz/rustls/blob/master/audit/TLS-01-report.pdf
======
EE84M3i
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?

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

~~~
EE84M3i
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.

------
tracker1
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.

~~~
yyyk
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.

~~~
fluffything
> 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.

~~~
wwright
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.

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

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

------
geofft
Some more discussion earlier today:
[https://news.ycombinator.com/item?id=23520004](https://news.ycombinator.com/item?id=23520004)

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

~~~
dathinab
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.

~~~
viraptor
> 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](https://tobtu.com/decryptocat.php)) as
well as widely disputed security claims.

~~~
brohee
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.

~~~
Harvesterify
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.

~~~
brohee
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...](https://web.archive.org/web/20160407125207/https://crypto.cat/security.html)
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...](https://www.courtlistener.com/docket/14868600/todd-v-reichwein/)
biased me...

