OpenSSL after Heartbleed(lwn.net) |
OpenSSL after Heartbleed(lwn.net) |
... and just a few days later they closed ~ 150 bugs, some with patches attached, "because they were too old":
https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/
https://mta.openssl.org/pipermail/openssl-dev/2016-October/0...
If it was anything other than a security library, it would have died long ago.
Another thing I'd like to ramble about a bit is their API/release management. In 1.1 they made a bunch of structures opaque - which is good IMHO - but due to the very inconsistent APIs before they needed to add some utility APIs to handle opaque structs in some places; instead of backporting those to 1.0.x, so that you, as an application developer, don't need to add conditional compilation and shims to every application, they chose not to. Additionally shims posted in the wiki were (maybe still are) wrong.
Forcing application developers to figure out API compatibility code for a crypto library is bad. That code will be tested very little or not at all, additionally it's hard to test.
Cryptography on Linux (or - on most platforms) is still in a bad shape.
libsodium addresses the non-TLS part of this pretty well, doesn't it? I know it doesn't have any native password-based KDF that won't DOS your device under anything but simple load, but otherwise it uses good algorithms.
> today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration.
True, but there are some nice-looking AEAD candidates in the CAESAR competition, some of which out-perform AES-GCM and CHACHA20 by a good margin. We'd probably all be using OCB mode if Rogaway hadn't used such a bizarre initial license (which took a few iterations to get in a sane state and still require you to pay him something like $70,000 USD for use in commercial embedded systems).
Having worked with Windows and OS X crypto layers, OpenSSL, CryptoPP and libtomcrypt, I think that generally cryptography is in bad shape almost everywhere.
The libraries that are trying to improve the cryptography aspects tend to run into the issue that algorithms in heavy use are unsupported. The libraries that do support algorithms in heavy use tend to have poorly written code, convoluted APIs, or bad documentation.
I have a huge amount of respect for everyone doing work in this space. When things are working, most people ignore it, but when sometimes goes wrong, everyone is mad at you. I would imagine there isn’t a whole lot of motivation for most.
I'm also curious how LibreSSL is doing—I haven't heard much about it lately. Did it fizzle, or is it still making good progress?
There's a good summary of LibreSSL's track record over the past two years in comparison with OpenSSL on the LibreSSL Wikipedia page (https://en.wikipedia.org/wiki/LibreSSL#Security_and_vulnerab...).
There was also news a few days ago (https://news.ycombinator.com/item?id=12691733) that Alpine Linux is adopting LibreSSL Portable in place of OpenSSL.
It's pennies for them, they wouldn't even see it on the balance. Having security issues slows down business significantly. Non-geeks keep hearing about major bugs in basic security and it surely has a negative effect on the spread of internet and services based on it.
It was a catastrophic failure of a critical internet component that highlighted the truth that these supposed crypto security experts didnt have a clue.
We're talking about the kind of "simple bug" analogous to a television with bare wires as a power switch.
Imho it will take a lot more than a couple of years and a team change to reinspire faith in that brand of security. If we should at all.
That's not really true: per https://www.bis.doc.gov/index.php/policy-guidance/encryption..., publicly available software (which includes free software) just requires a notification under exception TSU. All you have to do, per https://www.law.cornell.edu/cfr/text/15/740.13, is send an email to crypt@bis.doc.gov and to enc@nsa.gov with the location of the source code. As long as you don't change the location, you never have to worry about it again.
The regulation even notes that simply providing source code on a public website does not constitute export to a prohibited country.
It's really not a big deal.
(Note: I am not a lawyer; this does not constitute legal advice)
Does anyone have any info on this tool? I'm intrigued.
BoringSSL[1] is Google's attempt.
[0] https://www.libressl.org/ [1] https://boringssl.googlesource.com/boringssl/
BoringSSL is similar, except there you additionally have the problem that google strongly discourages its use by third parties, as they consider it an internal library and semantics can change.
A better example of a modern library would be NaCL or libsodium.
The reason for the fork was not Heartbleed itself but the crazy memory allocation done behind the scenes.
An early example was Guttman's cryptlib which is dual-licensed:
https://en.wikipedia.org/wiki/Cryptlib
Note: An interesting feature of it is that it embeds a security kernel that tries to ensure the algorithms are composed correctly.
Another dual-licensed one that seemed to at least have better code quality was PolarSSL used in Fox-IT's OpenVPN-NL project and partially verified by TrustinSoft's analyzer:
MatrixSSL is another one aiming at small, efficient execution:
https://www.insidesecure.com/Products-Technologies/Protocol-...
Save the best for last in Amazon's s2. It has much potential coming from the combo of simplicity, design-for-verification, and actual reviews by pentesters:
https://github.com/awslabs/s2n
Note: There's also quite a few designed for robustness in smartcard industry. The EAL5+ one from IBM's Caernarvon team is likely to be high quality. The thing is we can't review them but we can review above code. So better to go with above. Also recall this list is of commercial replacements for SSL in addition to others' recommendations on LibreSSL, BoringSSL, etc.
That shows up on the balance sheet of the security-infrastructure team even of Microsoft or Google.
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.
"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.
It's happening: https://github.com/ctz/rustls
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.
I suspect that assembler for the primitives and a good, sane high-level language (Haskell? Caml? Lisp?) would yield far more secure software than C. There are issues with relocatable memory and zeroing of keys, but those are, I think, addressable at the implementation level.
That would mean not wrapping the whole OpenSSL library in Rust calls but having some as minimal as possible, the tightest of the tightest loops implemented in ASM and everything else in clean and "secure" (not downgraded to the C freedom) Rust which would also pass the benchmarks and be capable to be called "on the high level" from the C code to which that library could be linked (probably the Rust code would not use GC or if it would it would have to be some so simple and minimal one that it would work by eventually calling the C malloc for bigger blocks and cause no different delays than the good written C). Not easy but I think theoretically possible for Rust. Once it would be achieved, implementing other algorithms would be possible to be done by different people and organizations.
I guess in order to achieve these goals the language designers would have to directly decide to support them, but I'd be glad if the status is already different. But I really believe that would be a huge argument for Rust: being provably more secure than C and achieving ability to implement effective drop-in replacements for C security libraries. Is it too high a goal?
I don't know how far we are from something like that, but maybe some Rust insider can estimate? What's still missing and how far we are from the point where what I described would be possible to implement?
Otherwise it's a nice library. So if it works for a project I highly recommend it.
--
I really hope that CAESAR moves the state of AEAD forwards. By all accounts it already has.
https://web.archive.org/web/20120805001248/http://www.openss...
August 2015 is just when they did a website redesign, which caused some URLs to change.
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?
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.
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.
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.
Which is something impossible in C, where even using plain vectors, strings or doing arithmetic requires unsafe code.
It is easier to vet lets say 10% of the code than 100%.
And yet, despite all of that not using these protective measures is considered by every reasonable person as incredibly stupid and worthy of a darwin award. This goes so far that there are laws that regulate this.
Nevertheless somehow when it comes to software all of that goes out the window. There is risk to other peoples money, privacy and potentially their lives? Who gives a shit? It doesn't make everything a 100% safe so let's use decades old tools that are difficult to learn are horrible to work with, allow for a huge number of completely preventable mistakes to happen, that we know happen often.
In any other context people would never come up with such a criticism. It would be considered ridiculously stupid to the point that some might think you're being sarcastic and making a joke and once they discover they not, they'd ask if there are some mental problems that might require attention.
Rust and languages that go into that direction don't solve all our problems and that's completely irrelevant.
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.
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.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
All kinds of things could solve the C-level problems or substitute with a C wrapper but nobody cares enough to do it.
They even made the "security" annex optional in C11!
https://github.com/mirleft/ocaml-tls
It's performance was within 80% or so of regular TLS with Ocaml's safety and easier verification. Quite a few components were purely functional, too. I've seen SML embedded in LISP's and PreScheme compiled to efficient C or ASM. So, that means a static LISP could handle it piggybacking on C compilers. Ivory embeds a subset of C in Haskell to keep things easy to analyze and automatically safe. Parts of a SSL library could use it.
http://ivorylang.org/ivory-introduction.html
So, Haskell, LISP, and ML are already capable of replacing our SSL libraries if people choose. One is already done in Ocaml. COGENT, if people apply it to this, will take it further by having an easier-to-verify implementation in functional language with certified compilation to C or assembly.
https://project-everest.github.io/
https://fstarlang.github.io/general/2016/09/30/introducing-k...
Presented at this year's ICFP conference.
The other thing I noted is that most code meant for verification is designed to be easy for humans or machines. The F star and C is one of few that is easy for both. I rarely see that.
https://crates.io/crates/rustls is a TLS library built on top of ring.
Edit: Re "just know they exist" (meaning libraries) in the answer: That's why I started the topic, the people who use only C wouldn't have chance to try the library unless the people who know enough Rust give something explicit that works and can be actually tested in linkability, functionality and speed.
> Does it depend on the GC?
I am not sure about your other questions, as I haven't used them directly, I just know they exist. :) The former is possible, but I don't know if the authors have done any work on that.
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? :)
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.
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.
"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...
That's not universally true. Compiler people tell me some optimizations happen using undefined behavior. Personal experience shows some, esp hand-optimized assembly, rely on stuff that a static analyzer just couldn't handle. These are common in compression, encryption, and multimedia libraries. So, you indeed might sacrifice performance writing code in a language that can knock out all kinds of problems at compile time working within the coding style it needs to do that.
In the general case, though, your point holds so far as lots of problems can be knocked out at compile time without affecting performance enough for the user to care.
Edit: also thanks for explaining the nature of the solutions you mention ("custom jobs").
"SaferCPlusPlus just introduces a memory-safe subset of C++ as an option."
True. This has at least basic benefit.
" Namely, portability and, more importantly, dependency risk."
What was the portability issue?
"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. "
This would be a good selling point to enterprise customers or large FOSS projects that use C++.
> What was the portability issue?
Oh, it was a long time ago that I investigated it and I don't remember the details very clearly, but for one, I needed a solution that supported Windows. Either it didn't support Windows, or its support for Windows was obsolete or something. I don't really remember. And iirc, it used assembly code and platform specific hacks to try to determine if an object was allocated on the stack or not. Yeah, I don't really remember the details, but it wasn't my intention to develop SaferCPlusPlus. If I could've gotten Ironclad to work for me, I probably would've been happy with that.
> This would be a good selling point to enterprise customers
Yeah, unfortunately I'm not selling anything, otherwise there would be marketing budget :)
[1] https://github.com/google/sanitizers/wiki/AddressSanitizerIn...
"And iirc, it used assembly code and platform specific hacks to try to determine if an object was allocated on the stack or not."
My plan was to get some academics with an appreciation for making money to dig into it for non-sense like that, test its mechanisms, clean it up, and put in a concurrent, low-latency scheme for dynamic stuff. Then test it against common compilers and FOSS codebases before marketing it to companies to get some safety in various apps. :)
Of course, I have limited influence in current condition and you have no marketing budget for yours. Progress on Great Change stalls once again. Least you're keeping at your own project that might turn into something later.