4 ms·

Is it really extensively tested? Should one even write these kinds of libraries in C?

by 77pt77 6y ago

yabadubakta 6y ago
Oh great, here we go again... I mean, which OS is available in something other than C? Frankly, C has gotten us quite far in the systems engineering space. No matter what language, bugs will surface. Starting over on the hype-train isn’t always the best idea!
tptacek 6y ago
In an ideal world, if you could get the same calibre of talent patrolling the Rust port of OpenSSL and everyone using it, of course you'd want the Rust version. We live in a fallen world. For a lot of software, the Rust-Go/legacy-C decision is trivial; you'd always take the Rust or Go. But OpenSSL is a tricky case and you can see why in today's announcement: there's a crasher memory corruption problem (but you can crash Rust programs too! today's bug is like a bad "unwrap"). But the first bug is an X.509 logic problem and I don't believe any practical language forecloses on those. Meanwhile: OpenSSL gets a lot of attention and has a lot of built-up institutional knowledge that other libraries don't. I probably trust it more than I trust any of the other C-language TLS libraries.
- tedunangst 6y ago
  In rust, you'd just make a ValidCert type and then it can never be invalid.
- kaliszad 6y ago
  The problem seems deeper. From my overview of the hardware/ software interface deep down bellow our infrastructure we have built on top, modern CPUs, assembly, systems programming languages and compilers make it extra hard to do cryptography right. As I understand, most of the stuff is written with "in our experience it is constant time" attitude but I don't think it is guaranteed. CPUs can internally reorder stuff (basically the whole Spectre/ Meltdown and other timing related attacks use this) and we cannot be 100% sure basically about anything. Introduce compilers in the stack and some new optimizations might make previously constant time functions variable time under some circumstances. Of course OpenSSL is a huge project and mixes many concerns, hard-to-use-right APIs and support for many platforms. This is basically the opposite of what cryptographers and security minded engineers strive for. On the other hand, I am not a cryptographer myself, I am not a C/ Rust/ Assembly or whatever master and I am very far from really understanding modern CPUs though I probably understand a lot more than the average programmer or sysadmin. I just have the feeling with security, that it is a game of whack-a-mole rather than systematic engineering at times and that doesn't seem to be a sustainable approach.
- perihelions 6y ago
  "But the first bug is an X.509 logic problem and I don't believe any practical language forecloses on those." I'm likely wrong (this isn't my field), but isn't this particular logic bug avoided by exhaustive enums? I understand this bug took the form of (1) a var was assigned an enum type, encoding a logic state ("which X.509 error") (2) the var gets passed around to different functions, which handle the enum values case-by-case (3) an update adds a new logic state at (1) (explicit ECC params), but doesn't update the case handling at (2) to handle the new value. Plus, since the error types overwrite each other into the same field, the new error type can clobber an older error type so that they both go unhandled. If you use strict, exhaustive enums, this type of bug is excluded (isn't it?) The type of the enum will propagate to every place it's read, and the compiler will flag the non-exhaustive case handling in the stale code.
  - tptacek 6y ago
    I don't know about that. Look at the diff, it looks like a counting bug. Rust programs also use counting logic, including in places where you could in theory model with exhaustive enums, but nobody does.
- SilverRed 6y ago
  Crashing is fine. Continuing with unknown behavior is bad. With rust you might find some obscure bug which lets you crash the software and then docker/k8s/systemd will restart it automatically. The worst you could do is spam the bug and dos the server. But at least no user data is compromised.
marcosdumay 6y ago
There are some issues with cryptographic code in high level languages, so I'm not sure what is better. Even C is considered too high level some times.

Is it really extensively tested? Should one even write these kinds of libraries in C?

by 77pt77 6y ago

Is it really extensively tested? Should one even write these kinds of libraries in C?

Oh great, here we go again... I mean, which OS is available in something other than C? Frankly, C has gotten us quite far in the systems engineering space. No matter what language, bugs will surface. Starting over on the hype-train isn’t always the best idea!

tptacek 6y ago

In an ideal world, if you could get the same calibre of talent patrolling the Rust port of OpenSSL and everyone using it, of course you'd want the Rust version. We live in a fallen world. For a lot of software, the Rust-Go/legacy-C decision is trivial; you'd always take the Rust or Go. But OpenSSL is a tricky case and you can see why in today's announcement: there's a crasher memory corruption problem (but you can crash Rust programs too! today's bug is like a bad "unwrap"). But the first bug is an X.509 logic problem and I don't believe any practical language forecloses on those. Meanwhile: OpenSSL gets a lot of attention and has a lot of built-up institutional knowledge that other libraries don't. I probably trust it more than I trust any of the other C-language TLS libraries.

tedunangst 6y ago
In rust, you'd just make a ValidCert type and then it can never be invalid.
kaliszad 6y ago
The problem seems deeper. From my overview of the hardware/ software interface deep down bellow our infrastructure we have built on top, modern CPUs, assembly, systems programming languages and compilers make it extra hard to do cryptography right. As I understand, most of the stuff is written with "in our experience it is constant time" attitude but I don't think it is guaranteed. CPUs can internally reorder stuff (basically the whole Spectre/ Meltdown and other timing related attacks use this) and we cannot be 100% sure basically about anything. Introduce compilers in the stack and some new optimizations might make previously constant time functions variable time under some circumstances. Of course OpenSSL is a huge project and mixes many concerns, hard-to-use-right APIs and support for many platforms. This is basically the opposite of what cryptographers and security minded engineers strive for. On the other hand, I am not a cryptographer myself, I am not a C/ Rust/ Assembly or whatever master and I am very far from really understanding modern CPUs though I probably understand a lot more than the average programmer or sysadmin. I just have the feeling with security, that it is a game of whack-a-mole rather than systematic engineering at times and that doesn't seem to be a sustainable approach.
perihelions 6y ago
"But the first bug is an X.509 logic problem and I don't believe any practical language forecloses on those." I'm likely wrong (this isn't my field), but isn't this particular logic bug avoided by exhaustive enums? I understand this bug took the form of (1) a var was assigned an enum type, encoding a logic state ("which X.509 error") (2) the var gets passed around to different functions, which handle the enum values case-by-case (3) an update adds a new logic state at (1) (explicit ECC params), but doesn't update the case handling at (2) to handle the new value. Plus, since the error types overwrite each other into the same field, the new error type can clobber an older error type so that they both go unhandled. If you use strict, exhaustive enums, this type of bug is excluded (isn't it?) The type of the enum will propagate to every place it's read, and the compiler will flag the non-exhaustive case handling in the stale code.
- tptacek 6y ago
  I don't know about that. Look at the diff, it looks like a counting bug. Rust programs also use counting logic, including in places where you could in theory model with exhaustive enums, but nobody does.
SilverRed 6y ago
Crashing is fine. Continuing with unknown behavior is bad. With rust you might find some obscure bug which lets you crash the software and then docker/k8s/systemd will restart it automatically. The worst you could do is spam the bug and dos the server. But at least no user data is compromised.

marcosdumay 6y ago

There are some issues with cryptographic code in high level languages, so I'm not sure what is better. Even C is considered too high level some times.