[dijit]

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.

[dom0]

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]

Windows' crypt32 also matters, and has a much cleaner API compared to OpenSSL, with backwards compat.

[DasIch]

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]

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

[nickpsecurity]

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]

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

[mSparks]

"Safe/Secure" code - by definition must be slower than unsafe code.

Because every operation must pass over a series of hurdles to make sure it is safe. - does the code have permission to do this, is everything being supplied within bounds, is the system in a stable state.

Every language is about the same with all these checks in place. In fact C is quite possibly slower, because so many of the memory jumps will be so far away, and compilers are much better at optimising for this than people.

In my opinion not having these checks is only acceptable when the permissions of all developers and all users - potential and actual are identical. While there are rare cases this is true, much to many developers chargrin, in nearly every case it is not.

The whole point of SSL is that developers, users and users of the users permissions are totally different.

[DasIch]

This isn't true at all. The language has an impact on whether you can make perform these checks at runtime or at compile time. If you can do them at compile time, performance isn't affected at all and the code won't run slower.

[nickpsecurity]

"Like several times slower that executables compiled normally. "

That's usually true if it's a naive scheme for safety. The main benefit of clever ones like Softbound+CETS or SAFEcode is they try to optimize away a lot of that. The first, SAFEcode paper reported worst-case of 30% overhead in their tests. SVA-OS overhead was mostly well under 2x with a few cases that did 2-4x. I can't remember what the S+C was. Remember that these also knock out almost every root cause of code injections in C apps with SVA-OS covering whole Linux kernel. Might be worth buying a second CPU to cover the overheads. ;)

"The TOR project tried to build firefox using them, but they couldn't successfully build it"

I wasn't aware of that. Thanks for telling me. Shows some work needs to be done. Would've been nice if they were more specific than "they didn't work." I was holding off on applying them to Tor anyway since such services must do covert-channel analyses. I'm not sure what effect these techs have on that. I recommended redoing it in SPARK Ada with Kemmerer's method for covert channel analysis.

"And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives."

I disagree. The reason is that there's way more tooling for statically analyzing, verifying, certifying object code of, and so on for C programs. Very little for C++ in comparison. So, taking up C++ gives you the few measures of safety it provides while forgoing tech you can get in C such as Astree Analyzer or CompCert. Too much a sacrifice. People stuck in legacy codebases might want to apply or improve on Ironclad, though.

http://acg.cis.upenn.edu/papers/ironclad-oopsla.pdf

https://github.com/crdelozier/ironclad

[duneroadrunner]

Not my area of expertise, but a little googling yields:

"SAFECode performance was reduced on average by a factor of 41.72 times, and the average slowdown for SoftBound was 5.36 (that is, a program runs 5.36 times slower with bounds checking than without it)." [1]

As for the C versus C++ question, I don't take a position on that. The practicality of sticking with straight C (or some subset) will vary by project. SaferCPlusPlus just introduces a memory-safe subset of C++ as an option. But a subset that doesn't require the re-architecting of existing C/C++ code as it provides safe compatible substitutes for C/C++'s unsafe elements.

> People stuck in legacy codebases might want to apply or improve on Ironclad, though.

SaferCPlusPlus only exists because Ironclad was/is not a practical solution. In particular because Ironclad is abandonware. In my opinion, Ironclad was a brilliant and impressive solution. SaferCPlusPlus strives to be a solution in the same vein, but one that takes advantage of modern C++ in its implementation. The non-viability of Ironclad exposed key problems shared with many other approaches. Namely, portability and, more importantly, dependency risk. SaferCPlusPlus is just a simple open source library written in pure, portable C++. It works on any platform with a reasonably modern C++ compiler. If you adopt it and at some point in the future it becomes abandonware, there is no risk to your project. It will continue to build properly, and the code won't be stuck with some idiosyncratic paradigm that will interfere with future coding strategies. And the library is simple enough that it should be fairly easy to add new features or customizations as needed.

[1] https://www.semanticscholar.org/paper/Performance-of-Compile...

[pjmlp]

I doubt anyone in C community would turn them on anyway.

They even made the "security" annex optional in C11!

[duneroadrunner]

Well that's just it, use of the sanitizers is not up to the developers, it's a build-time option. The TOR guys have enabled them when building firefox[1]. But apparently some of their debugging features actually introduce potential vulnerabilities themselves so they're not really appropriate for deployed executables. Yet.

[1] https://blog.torproject.org/category/tags/tbb-hardened

[lmm]

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