Comment by briansmith | Hacker News Reader

Comment by briansmith | Hacker News Reader

Parent Full thread

> Attacks like downgrade attacks, for example, are not memory unsafety issues.

First, this library only implements TLS 1.2 with AEAD cipher suites (AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305) and perfect forward secrecy (using ECDHE with the X25519, P-256, and P-384 curves, and RSA and ECDSA signatures). Thus, downgrade to something worse than what NSS or OpenSSL or BoringSSL consider to be the very best crypto is avoided at a very fundamental level.

Second, I and other people have been advocating strongly against design decisions that force implementations to add downgrade vectors. In particular, there is a version number field in the TLS ClientHello that we know causes problems. People have proposed solutions to avoid this version number causing compatibility problems for TLS 1.3, but Mozilla's TLS people have not supported making this improvement. Thus, we're likely going to have downgrade issues by design in TLS 1.3 that would be completely avoidable, due in large part to the people making NSS and other C crypto libraries.

Despite that, Manishearth is correct that they should rely on a battle-tested library instead of just Rust. That's just one kind of issue. The main ones will be:

1. Abstraction gap issues where security analysis of algorithm/protocol didn't reflect a realistic implementation. Padding errors were an old example of that.

2. Issues with each individual component where it might have not been instantiated or removed correctly.

3. Interface errors where things were connected in a dangerous way. Examples include wrong ordering or meet-in-middle.

4. Parsing errors.

5. Memory safety issues.

6. Compiler optimizations introducing security issues or removing security checks.

7. Covert storage or timing channels. Mainstream INFOSEC have re-discovered them as "side channels." I'm not sure you can even do covert, channel analysis in Rust yet as it requires a clear mapping from language to assembler. Most projects just ignore this requirement although BoringSSL addresses it with hand-coded assembly as you pointed out.

So, there's a lot of ground to cover implementing even a straight-forward, crypto protocol to ensure it's secure. Most of that has nothing to do with the protections Rust offers. Matter of fact, it might be a step back in many ways due to immature (or non-existent) tooling for specific requirements on the list. Side-by-side SPARK and MISRA C implementations with design-by-contract and some assembly are the strongest here for now.

Keep at your project, though. Your longer comment detailing the work was quite impressive. Great work. Even better that you're gradually tweaking one that already works in real-world deployments. Will avoid many issues that way.

This is good. However, I mentioned downgrade attacks as an example of the kind of bug Rust can't solve. Most likely new TLS stacks will not be prone to downgrade attacks. They might be prone to other logic errors. So will established TLS stacks, but those are more battle tested. The rust ones will be too, but eventually, not now.

It's a tradeoff.

Out of curiousity, what sort of evidence of safety is the Servo team using to evaluate crypto libraries? I'd love to see the criteria.

I'm not aware of the details.

As we mentioned in the recent Security meetings notes (https://github.com/servo/servo/wiki/London-Security ), there will be a blog post on blog.servo.org in the coming weeks from the folks on the team who are making these decisions.

Reply on news.ycombinator.com