Item — HN Reader

I am a maintainer for 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....)

(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.)

7 comments

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

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?

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

We try very hard to model our code as a constrained state machine that closely follows the specification.

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

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.

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.

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.

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.

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.

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.

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

TLS 1.0 support.

What do you need TLS 1.0 support for?

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.

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.

Replying to myself: TLS 1.0 is now officially deprecated.

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