4 ms·

I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we sho

by DasIch 10y ago

I think that's somewhat unfair. People make mistakes, that's unavoidable and shouldn't be seen as an issue. Instead of blaming people for making mistakes we should consider what we can learn. We need to identify which mistakes happened, why they happened and what measures we can take to make such mistakes impossible or unlikely in the future. It turns out that the industry is really bad that problem. Many libraries and critical parts of the infrastructure are developed using languages and tools that don't just allow mistakes to happen that can be prevented but make it easy to make such mistakes. Crypto is affected by this but there are many other areas which are affected by this problem to. There needs to be a move towards more constrained languages like Rust that limit the potential mistakes, better development processes that prevent bugs from passing through that can be caught by humans and tools for testing that make it possible to test for a wider range of problems and not just those developers anticipate to occur.

dijit 10y ago
I see the same sentiment all the time here on HN. "Just reimplement it in rust" Well, why do you think openssl is so pervasive? It's everywhere and it's not due to marketing or ease of use or code quality. It's because nobody in their right mind wants to implement a TLS library. Openssl itself was only conceived because the original author was teaching himself C.
- DasIch 10y ago
  I'm mentioning Rust to make clear the direction I'd like things to go and because there isn't really an alternative that allows for similar reusability and is practical for developing cryptographic libraries. That being said there are also implementations of TLS in other languages like Haskell or OCaml, that also wouldn't be vulnerable to these kinds of issues. I agree that this is a difficult problem but I don't think that's really the barrier here. AI is also difficult and there is no shortage of improvement in that area. The real problem isn't the difficulty of implementing a TLS library, the real problem is inertia and an unwillingness to change.
  - duneroadrunner 10y ago
    SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
    - nickpsecurity 10y ago
      I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used. All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.
      - duneroadrunner 10y ago
        SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to build firefox using them, but they couldn't successfully build it [1]. Perhaps nobody cared to address the C/C++ (memory) safety problems when the solutions required significant compromise. But the santizers are now (or could be with a little effort) a much more practical "no code modification required" solution than the previous options. And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives. Maybe these new and improved choices will make a difference. We can dream, can't we? :) [1] https://blog.torproject.org/category/tags/tbb-hardened https://blog.torproject.org/category/tags/tbb-hardened
- dom0 10y ago
  Another facet is that full compatibility to OpenSSL is required on the internet. Ten years ago plenty of projects were using alternative SSL implementations (eg Peter Gutmann's cryptlib), many of which had slight interop problems with OpenSSL (which one to blame is impossible to say). In turn many projects switched away from these libraries - they had to, interop issues making software unreliable are vexing for every user - and moved to OpenSSL. OpenSSL will also often be the first implementation that has a new TLS feature, it's the internet's demo implementation. New optimizations in algorithms tend to land first in OpenSSL as well etc. Today there are like ~four or five relevant TLS implementations, and only one is in widespread use on servers.
  - my123 10y ago
    Windows' crypt32 also matters, and has a much cleaner API compared to OpenSSL, with backwards compat.
- lmm 10y ago
  There are options now though. My production services terminate SSL with a non-C implementation. (ocaml-ssl may be beta and unaudited but my judgement call is that I trust it more than any C implementation).
mSparks 10y ago
Tell that to your bank manager when they make a mistake.... It is NOT the bug itself that is at issue here. It is the "mistake" of an ENTIRE INDUSTRY relying on a security module with haphazard, proven flawed development process, and impenetrable code. Then trying to pretend the exact opposite. Unfair, attract me down votes - sure. True - without doubt.
- DasIch 10y ago
  So? Nobody disagrees on the fact that there is a problem. Putting blame on people won't solve the problem. It will piss people off. People you want on your side, enthusiastically solving the problem. Your attitude is actually dangerous and counterproductive to solving the problem. This toxic culture is a big part why we are in this mess. Who in their right mind would want to try work on OpenSSL to improve it while being called an idiot? Who'd be willing to stand up for the project as a representative? Speak out for the project?
  - mSparks 10y ago
    It's not a case of blaming. Its a case of choosing https://www.libressl.org/ https://www.libressl.org/ or https://www.openssl.org/ https://www.openssl.org/ Applying best practice development processes or Pretending someone else can do it all for you, and you can "bolt it on" at the end. The article lists: Future plans and lessons learned: At the top of the list for future development is support for TLS 1.3. Like adding yet another protocol to the already hacked mess of protocols is a "good" thing.
    - DasIch 10y ago
      LibreSSL is only better because it does less and much more human attention is wasted on producing bug free C code. That's an improvement but it's quite limited.
whyever 10y ago
> There needs to be a move towards more constrained languages like Rust that limit the potential mistakes It's happening: https://github.com/ctz/rustls https://github.com/ctz/rustls
sidlls 10y ago
Rust guarantees safety under certain conditions. That's it. It doesn't guarantee good design, bug free code, or code that never behaves badly. This is the kind of gratuitous maligning of code written in other languages that some Rust fans engage in that I find off-putting. Rust isn't The Solution To All Our Problems.
- pjmlp 10y ago
  You are right, but any systems programming language that comes from the Algol or ML family doesn't suffer from "every line of code is a possible memory corruption" that C and its derivatives suffer from. Rust or any other memory safe systems programming languages don't make all type of programming errors go away, but at least they make the memory corruption ones less likely to happen. Also most of the C tools that help reduce memory corruption, if not hardware assisted like on SPARC v9 and Skylake, are mostly limited to having all source code available. It feels like moving from Assembly to an higher level programming language.
  - sidlls 10y ago
    I mostly agree. However I have this prediction: if Rust gains popularity, then in 5-10 years (or perhaps fewer!) someone will be complaining about memory issues in a Rust library that is peppered with "unsafe" blocks that don't properly respect the safe/unsafe boundary contract. Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Safe Rust. Human-vetted things are prone to error, no matter how good the humans doing the vetting are.
    - burntsushi 10y ago
      > Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Safe Rust. Human-vetted things are prone to error, no matter how good the humans doing the vetting are. At some point, it has to be human vetted. I don't see another way. The key advantage is the ability to build safe abstractions from unsafe components. Will people abuse unsafe? Absolutely. Is it a lot better than the alternatives? IMO, absolutely. :-) In my own experience, unsafe is rarely needed. I've only ever used it for ffi and lightly in very performance critical areas of code. The regex library, for example, has almost no unsafe. Its only use is to get rid of bound checks inside the DFA's inner loop. The most (non-ffi) unsafe I've ever used is in a snappy compression library, where most of it was a means to more efficiently shuffle bytes around without paying for memcpy (using unaligned 8 byte or 16 byte loads/stores). There is a pretty strong tendency in the Rust community to avoid unsafe. Some libraries advertise themselves as having "no unsafe code" as a selling point precisely for the dangers you've hinted at: humans make mistakes.

by DasIch 10y ago

dijit 10y ago

I see the same sentiment all the time here on HN. "Just reimplement it in rust" Well, why do you think openssl is so pervasive? It's everywhere and it's not due to marketing or ease of use or code quality. It's because nobody in their right mind wants to implement a TLS library. Openssl itself was only conceived because the original author was teaching himself C.

DasIch 10y ago
I'm mentioning Rust to make clear the direction I'd like things to go and because there isn't really an alternative that allows for similar reusability and is practical for developing cryptographic libraries. That being said there are also implementations of TLS in other languages like Haskell or OCaml, that also wouldn't be vulnerable to these kinds of issues. I agree that this is a difficult problem but I don't think that's really the barrier here. AI is also difficult and there is no shortage of improvement in that area. The real problem isn't the difficulty of implementing a TLS library, the real problem is inertia and an unwillingness to change.
- duneroadrunner 10y ago
  SaferCPlusPlus[1] is an easier option when starting from a C/C++ code base. It's also one of the faster options, but if people are willing to accept some performance cost, I think the easiest solution would probably be to "harden" the LLVM/gcc sanitizers so that they can be used in deployed builds, not just debug builds. The sanitizers don't catch everything, but pretty close it seems. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
  - nickpsecurity 10y ago
    I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used. All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.
    - duneroadrunner 10y ago
      SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to build firefox using them, but they couldn't successfully build it [1]. Perhaps nobody cared to address the C/C++ (memory) safety problems when the solutions required significant compromise. But the santizers are now (or could be with a little effort) a much more practical "no code modification required" solution than the previous options. And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives. Maybe these new and improved choices will make a difference. We can dream, can't we? :) [1] https://blog.torproject.org/category/tags/tbb-hardened https://blog.torproject.org/category/tags/tbb-hardened
dom0 10y ago
Another facet is that full compatibility to OpenSSL is required on the internet. Ten years ago plenty of projects were using alternative SSL implementations (eg Peter Gutmann's cryptlib), many of which had slight interop problems with OpenSSL (which one to blame is impossible to say). In turn many projects switched away from these libraries - they had to, interop issues making software unreliable are vexing for every user - and moved to OpenSSL. OpenSSL will also often be the first implementation that has a new TLS feature, it's the internet's demo implementation. New optimizations in algorithms tend to land first in OpenSSL as well etc. Today there are like ~four or five relevant TLS implementations, and only one is in widespread use on servers.
- my123 10y ago
  Windows' crypt32 also matters, and has a much cleaner API compared to OpenSSL, with backwards compat.
lmm 10y ago
There are options now though. My production services terminate SSL with a non-C implementation. (ocaml-ssl may be beta and unaudited but my judgement call is that I trust it more than any C implementation).

mSparks 10y ago

Tell that to your bank manager when they make a mistake.... It is NOT the bug itself that is at issue here. It is the "mistake" of an ENTIRE INDUSTRY relying on a security module with haphazard, proven flawed development process, and impenetrable code. Then trying to pretend the exact opposite. Unfair, attract me down votes - sure. True - without doubt.

DasIch 10y ago
So? Nobody disagrees on the fact that there is a problem. Putting blame on people won't solve the problem. It will piss people off. People you want on your side, enthusiastically solving the problem. Your attitude is actually dangerous and counterproductive to solving the problem. This toxic culture is a big part why we are in this mess. Who in their right mind would want to try work on OpenSSL to improve it while being called an idiot? Who'd be willing to stand up for the project as a representative? Speak out for the project?
- mSparks 10y ago
  It's not a case of blaming. Its a case of choosing https://www.libressl.org/ https://www.libressl.org/ or https://www.openssl.org/ https://www.openssl.org/ Applying best practice development processes or Pretending someone else can do it all for you, and you can "bolt it on" at the end. The article lists: Future plans and lessons learned: At the top of the list for future development is support for TLS 1.3. Like adding yet another protocol to the already hacked mess of protocols is a "good" thing.
  - DasIch 10y ago
    LibreSSL is only better because it does less and much more human attention is wasted on producing bug free C code. That's an improvement but it's quite limited.

whyever 10y ago

> There needs to be a move towards more constrained languages like Rust that limit the potential mistakes It's happening: https://github.com/ctz/rustls https://github.com/ctz/rustls

sidlls 10y ago

Rust guarantees safety under certain conditions. That's it. It doesn't guarantee good design, bug free code, or code that never behaves badly. This is the kind of gratuitous maligning of code written in other languages that some Rust fans engage in that I find off-putting. Rust isn't The Solution To All Our Problems.

pjmlp 10y ago
You are right, but any systems programming language that comes from the Algol or ML family doesn't suffer from "every line of code is a possible memory corruption" that C and its derivatives suffer from. Rust or any other memory safe systems programming languages don't make all type of programming errors go away, but at least they make the memory corruption ones less likely to happen. Also most of the C tools that help reduce memory corruption, if not hardware assisted like on SPARC v9 and Skylake, are mostly limited to having all source code available. It feels like moving from Assembly to an higher level programming language.
- sidlls 10y ago
  I mostly agree. However I have this prediction: if Rust gains popularity, then in 5-10 years (or perhaps fewer!) someone will be complaining about memory issues in a Rust library that is peppered with "unsafe" blocks that don't properly respect the safe/unsafe boundary contract. Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Safe Rust. Human-vetted things are prone to error, no matter how good the humans doing the vetting are.
  - burntsushi 10y ago
    > Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Safe Rust. Human-vetted things are prone to error, no matter how good the humans doing the vetting are. At some point, it has to be human vetted. I don't see another way. The key advantage is the ability to build safe abstractions from unsafe components. Will people abuse unsafe? Absolutely. Is it a lot better than the alternatives? IMO, absolutely. :-) In my own experience, unsafe is rarely needed. I've only ever used it for ffi and lightly in very performance critical areas of code. The regex library, for example, has almost no unsafe. Its only use is to get rid of bound checks inside the DFA's inner loop. The most (non-ffi) unsafe I've ever used is in a snappy compression library, where most of it was a means to more efficiently shuffle bytes around without paying for memcpy (using unaligned 8 byte or 16 byte loads/stores). There is a pretty strong tendency in the Rust community to avoid unsafe. Some libraries advertise themselves as having "no unsafe code" as a selling point precisely for the dangers you've hinted at: humans make mistakes.