4 ms·

I am a maintainer for rustls (https://github.com/ctz/rustls https://github.com/ctz/rustls). What would your team need to be able to migrate to a different TLS

I am a maintainer for rustls (https://github.com/ctz/rustls https://github.com/ctz/rustls). What would your team need to be able to migrate to a different TLS stack that so far has proven to be safer, and passed its first security audit with flying colors? (https://github.com/ctz/rustls/blob/main/audit/TLS-01-report.pdf https://github.com/ctz/rustls/blob/main/audit/TLS-01-report....) (I am also currently available on part-time freelance basis, feel free to contact me if you need commercial support on your endeavour to structurally address your TLS security issues.)

29athrowaway 6y ago
As soon as it becomes popular, it will be backdoored for sure.
sounds 6y ago
Apps build rustls into a fat binary, which doesn't get updated on day zero by the OS package manager. It requires a new release by the app maintainer for each app.
tedunangst 6y ago
TLS 1.0 support.
- ancarda 6y ago
  What do you need TLS 1.0 support for?
  - tedunangst 6y ago
    Talking to things that only support TLS 1.0. :( some old mail thing which doesn't know what year it is. I think min TLS 1.2 is probably fine for a new library, but I also think believing it's universal is pretty web centric.
    - SAI_Peregrinus 6y ago
      TLS 1.0 isn't secure. I'd rather insecure protocols and primitives not be included in a mainstream library. Maybe offer some extension library to allow support, but the default shouldn't have any risk of including such code in a way that it could be usable by a careless programmer. Same for MD5 and SHA1.
      - SAI_Peregrinus 6y ago
        Replying to myself: TLS 1.0 is now officially deprecated.
astrange 6y ago
The interesting thing about TLS state machine bugs is that they seem hard to prove nonexistence of ahead of time. Look at gotofail: https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html You can find it if you have a generic "suspicious looking code" check. And you can find it if you have a protocol regression test. But do you have a model of TLS that proves incorrect code paths like this don't exist?
- dochtman 6y ago
  We have some documentation on what we've done to learn from previous vulnerabilities: https://docs.rs/rustls/0.19.0/rustls/manual/index.html https://docs.rs/rustls/0.19.0/rustls/manual/index.html We try very hard to model our code as a constrained state machine that closely follows the specification.
  - astrange 6y ago
    That looks good. For your amusement I remembered another state machine bug in an SSH implementation: https://nakedsecurity.sophos.com/2018/10/17/serious-ssh-bug-lets-crooks-log-in-just-by-asking-nicely/ https://nakedsecurity.sophos.com/2018/10/17/serious-ssh-bug-... It included some server states in the client state machine, so if a client sent the server its own "authentication successful" message it… just let them in.
ancarda 6y ago
Any idea when rustls will hit 1.0? I feel a little unsafe using a <1.0 library because (assuming it's following SemVer) as it might not be "done"/production ready and the API might change a lot before it hits 1.0.
- dochtman 6y ago
  The API has generally been pretty stable, so I don't think you should be too worried about that. I haven't talked to other stakeholders about a version 1.0, and we actually have some larger API changes cooking right now. For now we probably value the ability to change the API more, especially because there are likely still ways we can make it more robust/secure.
CameronNemo 6y ago
Do you support ppc64le? WebAssembly? Not a requirement for me, but the fact that ring has no portable implementations is concerning. How do you verify correctness without a baseline? Evercrypt seems like a much better option on that front.
- dochtman 6y ago
  I think ring does support WebAssembly. Yeah, the ASM in ring is not great, but unfortunately Rust does not currently provide us with all the guarantees we need to write safe crypto code (for example, timing guarantees). We hope this will change fairly soon, though, so we can port all the underlying crypto to Rust.
Snawoot 6y ago
Feature completeness. There is no reason to preserve only ECDH-based cipher suites, for example.

29athrowaway 6y ago

As soon as it becomes popular, it will be backdoored for sure.

sounds 6y ago

Apps build rustls into a fat binary, which doesn't get updated on day zero by the OS package manager. It requires a new release by the app maintainer for each app.

tedunangst 6y ago

TLS 1.0 support.

ancarda 6y ago
What do you need TLS 1.0 support for?
- tedunangst 6y ago
  Talking to things that only support TLS 1.0. :( some old mail thing which doesn't know what year it is. I think min TLS 1.2 is probably fine for a new library, but I also think believing it's universal is pretty web centric.
  - SAI_Peregrinus 6y ago
    TLS 1.0 isn't secure. I'd rather insecure protocols and primitives not be included in a mainstream library. Maybe offer some extension library to allow support, but the default shouldn't have any risk of including such code in a way that it could be usable by a careless programmer. Same for MD5 and SHA1.
    - SAI_Peregrinus 6y ago
      Replying to myself: TLS 1.0 is now officially deprecated.

astrange 6y ago

The interesting thing about TLS state machine bugs is that they seem hard to prove nonexistence of ahead of time. Look at gotofail: https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html You can find it if you have a generic "suspicious looking code" check. And you can find it if you have a protocol regression test. But do you have a model of TLS that proves incorrect code paths like this don't exist?

dochtman 6y ago
We have some documentation on what we've done to learn from previous vulnerabilities: https://docs.rs/rustls/0.19.0/rustls/manual/index.html https://docs.rs/rustls/0.19.0/rustls/manual/index.html We try very hard to model our code as a constrained state machine that closely follows the specification.
- astrange 6y ago
  That looks good. For your amusement I remembered another state machine bug in an SSH implementation: https://nakedsecurity.sophos.com/2018/10/17/serious-ssh-bug-lets-crooks-log-in-just-by-asking-nicely/ https://nakedsecurity.sophos.com/2018/10/17/serious-ssh-bug-... It included some server states in the client state machine, so if a client sent the server its own "authentication successful" message it… just let them in.

ancarda 6y ago

Any idea when rustls will hit 1.0? I feel a little unsafe using a <1.0 library because (assuming it's following SemVer) as it might not be "done"/production ready and the API might change a lot before it hits 1.0.

dochtman 6y ago
The API has generally been pretty stable, so I don't think you should be too worried about that. I haven't talked to other stakeholders about a version 1.0, and we actually have some larger API changes cooking right now. For now we probably value the ability to change the API more, especially because there are likely still ways we can make it more robust/secure.

CameronNemo 6y ago

Do you support ppc64le? WebAssembly? Not a requirement for me, but the fact that ring has no portable implementations is concerning. How do you verify correctness without a baseline? Evercrypt seems like a much better option on that front.

dochtman 6y ago
I think ring does support WebAssembly. Yeah, the ASM in ring is not great, but unfortunately Rust does not currently provide us with all the guarantees we need to write safe crypto code (for example, timing guarantees). We hope this will change fairly soon, though, so we can port all the underlying crypto to Rust.

Snawoot 6y ago

Feature completeness. There is no reason to preserve only ECDH-based cipher suites, for example.