There is a lot of room for improvement in the current OpenSSL code base. Simple cleanups, for one. Code formatting. Removing duplicate code. Static analysis. Unit tests.

The OpenSSL maintainers seem to be doing something other than all that. The historical defence for this was that they had minimal funding (which is no longer true), and that the funding they did have was for adding new features.

That's just not an acceptable excuse. And it never was an acceptable excuse.

Cleaning up code should be part of normal software development. Re-factoring code, adding unit tests, etc. Adding static analysis builds (clang is free, and Coverity is free for open source projects).

It's 2016. Why are some people still using software practices from 1992?

They are cleaning up the code, which I noticed when porting PostgreSQL to OpenSSL 1.1 and things were broken all over the place. I just think the code base is very bad to start with and the cleanup just start very recently.

Has this been suggested to the OpenSSL devs? If so, what did they say? If not, adekok, perhaps you can do that. You are 100% correct here.

That's pretty much what the LibreSSL people have done. And no, they didn't get much response or buy-in.

There is https://github.com/mirleft/ocaml-tls which is used in MirageOS:

https://mirage.io/blog/introducing-ocaml-tls https://mirage.io/blog/ocaml-tls-api-internals-attacks-mitig... https://mirage.io/blog/why-ocaml-tls

There's https://nqsb.io - now even with a libtls.so compat layer (you can LD_PRELOAD our libnqsb-tls https://github.com/mirleft/libnqsb-tls)

Being binary compatible with libssl.so is just insane (too many symbols), but obviously doable. Volunteers welcome

Unfortunately that website doesn't load for me. Times out trying to connect to port 443. And the travis build bot says that the tls lib fails to build since about a month.

Looks like we're on a different Interweb, works for me; and travis was a spurious reporting problem, compiles fine (and is now green just to make you happy) :)

Do you know if there will be a video about this talk at OCaml 2016?

https://www.cl.cam.ac.uk/%7Ejdy22/papers/ocaml-inside-a-drop...

I guess it would pop up there: https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw/vid...

The more the merrier, thanks to it systems programing in memory safe languages is picking up support, from Ada getting more visibility in High Integrity Systems, Microsoft talking about their Midori research results[0] or Apple stating their goal with Swift is " Swift is intended as a replacement for C-based languages"[1].

Eventually we get the safety we had in the 90's back and improved.

[0] - https://www.infoq.com/presentations/csharp-systems-programmi...

[1] - https://swift.org/about/

Another choice is SaferCPlusPlus[0]. The transition could be done incrementally and the performance would be better than, say, C#.

[0] - https://github.com/duneroadrunner/SaferCPlusPlus (Note: shameless plug.)

The trouble with this isn't the lack of available options (indeed one may argue there are too many). But rather having everyone agree on something with a common API. Also has anything else seen heavy prolonged production usage?

I've read other people make this point. There are a lot of TLS implementations out there but OpenSSL was so synonymous with SSL/TLS for so long that it became a fundamental building block. If an API could be established that lets the-thing-that-does-TLS become a minor detail that's easily configured we'd all be better off.

Removing the dependency on OpenSSL is going to be a challenging, messy job. OpenBSD has mostly transitioned over to their LibTLS API but even they had difficulty moving some projects over.

A simpler, focused protocol framework and reference implementation with only necessary, useful options... something like that needs actual security people, users in embedded, enterprise, client/server apps would need to agree on it without falling into the trap of being hijacked by special interests, vague edge-cases and feature-creep. The issue would be that it's yet another/different standard, and TLS has most of the de-facto "market-share." That aside, OpenSSL and TLS are terrible because they're so poorly-managed, poorly-tested, poorly-validated, arbitrarily-featured and unplanned.

If SSL/TLS is a kitchen-sink, OpenSSL is Home Depot.

What features from those safer languages you want, that cannot be applied to existing OpenSSL code base? Pretty much everything they have is possible to implement for C without massive rewrites.

- Bounds checking

- Type safe enumerations

- Strings with guaranteed size (not missing '\0')

- No implicit conversions

- No undefined behaviour

- Validation of null pointers on access

- ...

And don't forget "use-after-free" avoidance. (Although technically "undefined behavior" covers a lot.)

Also, couldn't distros just provide a version of the library built with the AddressSanitizer[0] enabled as well? It would be slower, but should be much safer. Let the user choose? Not the ultimate solution, but for the short term.

[0] https://github.com/google/sanitizers/wiki/AddressSanitizer

If they really wanted to make memory-safe C happen, there are already SoftBound+CETS [1] and SAFECode [2] and other approaches. Rewriting all of the C libraries is just not a viable solution.

[1] http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/

[2] http://sva.cs.illinois.edu/index.html

Yeah, apparently the Tor project considered those first but they weren't able to compile Firefox [1]. And they seem to be abandonware at this point. I didn't immediately find any indication of their performance costs.

[1] https://blog.torproject.org/blog/tor-browser-55a4-hardened-r...

Worse than the performance impact is the problem that AddressSanitizer was designed to be a debugging tool and not to mitigate exploits in production.

http://seclists.org/oss-sec/2016/q1/363

I see. Interesting that the Tor project and others had the same idea though. I wonder how feasible it would be to derive an "AddressHardener" from the AddressSanitizer.

These all can, they just choose not to bother.

miTLS is a stack written in annotated F# and definitely a promising step in that direction https://github.com/mitls Unfortunately it doesn't offer a C-compatible ABI as far as I know, so not usable by native code applications.

Sure it is usable by native code. F* also has AOT compilers to native code.

F star compiles to Ocaml or F#. Here's the page on integrating Ocaml and C:

http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html

I'm not sure at a glance how easy it will be to use F star programs in C applications via Ocaml. We'd be better off if there was a compiler from F star to annotated/safe C, Ada/SPARK, or Rust. All of these can integrate more easily into the legacy apps.

Are you volunteering? Good luck and be sure not to repeat the various vulnerabilities that weren't related to memory safety.

I am not volunteering because while being fluent in C, I am not very knowledgeable in the realm of crypto. I'd be stupid to do otherwise. I can still point out that there is a big need for such a project.

This is a piece of software that is so core to our computer ecosystem that I am sure plenty of companies would contribute financially and with developer time. Heck, if this couldn't get enough funding for at least 5 fulltime devs plus external audits then we're in a sad state of an ecosystem. IMHO this actually should receive public funding. It would be more useful than many other things that get public funds.

Sigh. Please improve your reading comprehension. I didn't "shit on the LibreSSL developers". Anyways, you sound not like someone one can have a sensible conversation with. So I wont be replying further.

Don't worry, the rest of us get it.

Okay, let's have a sensible conversation about your completely idle suggestion to create a new library in some other language, that would have to maintain compatibility with the OpenSSL API otherwise no one will use it, or rewrite everything that currently uses OpenSSL.

To me your "LibreSSL is no such thing" came across as dismissing the efforts of LibreSSL, even though it's not vunerable to this latest one, because it doesn't use Erlang.