5 ms·

RusTLS Formal Audit [pdf]

156 points by dralley 6y ago

brohee 6y ago
It's now vetted by CryptoCat's author so it must be good.
- dathinab 6y ago
  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 6y ago
    > 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 6y ago
      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 6y ago
        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 6y ago
        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.cat/security.html 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-reichwein/ https://www.courtlistener.com/docket/14868600/todd-v-reichwe... biased me...
  - brohee 6y ago
    The point is that I absolutely don't trust one of them, but I guess the reference was too obscure for most.
EE84M3i 6y ago
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?
- deleted 6y ago
  [deleted]
- dutchmartin 6y ago
  They do, they mention it in the third paragraph of the introduction.
  - EE84M3i 6y ago
    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 6y ago
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.
- nextaccountic 6y ago
  Perhaps an entry point could be this project https://github.com/mesalock-linux/mesalink https://github.com/mesalock-linux/mesalink that provides an openssl-compatible interface for rustls.
  - rkangel 6y ago
    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.
    - adev_ 6y ago
      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 https://www.youtube.com/watch?v=Wd_dyRbE4AA
- Thaxll 6y ago
  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.
  - 6y ago
geofft 6y ago
Some more discussion earlier today: https://news.ycombinator.com/item?id=23520004 https://news.ycombinator.com/item?id=23520004

156 points by dralley 6y ago

brohee 6y ago

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

dathinab 6y ago
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 6y ago
  > 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 6y ago
    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 6y ago
      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 6y ago
        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.cat/security.html 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-reichwein/ https://www.courtlistener.com/docket/14868600/todd-v-reichwe... biased me...
- brohee 6y ago
  The point is that I absolutely don't trust one of them, but I guess the reference was too obscure for most.

EE84M3i 6y ago

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?

deleted 6y ago
[deleted]
dutchmartin 6y ago
They do, they mention it in the third paragraph of the introduction.
- EE84M3i 6y ago
  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 6y ago

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.

nextaccountic 6y ago
Perhaps an entry point could be this project https://github.com/mesalock-linux/mesalink https://github.com/mesalock-linux/mesalink that provides an openssl-compatible interface for rustls.
- rkangel 6y ago
  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.
  - adev_ 6y ago
    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 https://www.youtube.com/watch?v=Wd_dyRbE4AA
Thaxll 6y ago
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.
- 6y ago

geofft 6y ago

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