LibreSSL vs OpenSSL: The fork origin

In April 2014, a new security bug was found on OpenSSL, codename: Heartbleed. A detailled explanation can be found on wikipedia . To sum up: the implementation of the Heartbeat extension for TLS and DTLS is bugged in OpenSSL. This bug, a missing buffer size check on user provided data, allows an attacker connected to a server running openssl to extract and receive memory values from possibly protected areas. It appears feasible to bring OpenSSL implementation to leak server secrets including keys, internal values ... This bug has been fixed sine OpenSSL version 1.0.1g.
   This bug, considered a critical vulnerability registered as CVE-2014-0160) is sometime considered the reason for forking OpenSSL to LibreSSL. In April 2014, after a sorrow code audit, some OpenBSD developers (among them Bob Beck and Ted Unangst) forked OpenSSL 1.0.1f into LibreSSL. They generally point the poor code quality of OpenSSL as the main reason for forking it and cleaning it.
Their work lead them to:

• remove large parts of OpenSSL source , mostly for target support for architectures that very few people ever used
• clean other parts: deleting the unnecessary complex and it seems pretty much broken OpenSSL memory allocation/deallocation system. They replaced it with standard libc call (e.g.  malloc/calloc/reallocarray). Using those functions makes it more easy for standard checking tools to verify memory allocation/free schemes while maintaining better properties (e.g. multiplication overflow checking for calloc vs malloc).

LibreSSL became the de facto implementation for TLS in OpenBSD and some Linux distribution (e.g. arch) and has gained some momentum since. New features (e.g. ciphers based on Bernstein's chacha and poly 1305 or ANSSI EC) and new API (e.g libTLS) have been developed.
   Along with Google own fork of OpenSSL (Boring SSL) LibreSSL seems like a great initiative to improve security and maintainability of ex-SSL/TLS implementations. The previous security vulnerabilities have shown that it is important to keep a readable code base which can be audited by large community of skilled developer and cryptographer.
  In Parallel, it seems that it did a lot of good to OpenSSL itself, more developpers have been hired to work full time on the library. Since 2014, the library has been actively extended (Lots of cleaning, Async, Pipelining ...). The new version 1.1, released on August 25th 2016 provided a lot of expected changes and looks much as a renewal.

References:

1. Wikipedia's page on Heartbleed: https://en.wikipedia.org/wiki/Heartbleed
2. Heartbleed description (from Codenomicon) http://heartbleed.com/
3. Ted Unangst's article on the state of libreSSL fork from OpenSSL 30 days later: https://www.openbsd.org/papers/eurobsdcon2014-libressl.html
4. Reddit discussion on the subject: https://www.reddit.com/r/crypto/comments/3o2zy5/openssl_vs_libressl/
5. Bob Beck's slides on the new libTLS API for libreSSL http://www.openbsd.org/papers/libtls-fsec-2015/mgp00001.html
6. Wikipedia's page on LibreSSL: https://en.wikipedia.org/wiki/LibreSSL
7. LibreSSL website: http://www.libressl.org/
8. Article on OpenSSL team meeting after Heartbleed: http://qz.com/286210/how-an-unprecedented-face-to-face-meeting-of-11-geeks-will-make-the-internet-more-secure/

Short note: consequence of arithmetic overflow

This is not a full length article but simply a short note.
I recently came across a very interesting post on OpenSSL blog which detailed how a "bad" use of pointer arithmetic lead to a possible low-level security breach in the library. I will let the interested reader go through the original post to understand all the technical details and I will focus on a short explanation. In C90 pointer arithmetic is only defined/specified for malloc-ed pointers with operands less than the malloc-ed size, everything else is undefined behavior.
  It means that in the following example, len must be less or equal to SIZE for the test to work as expected, which makes it pretty much completely useless since this code is supposed to test that specific condition.

/* implied */
char* p = malloc(SIZE);

// buffer overflow detection
if (p + len < limit) {
  // manage overflow case
}

    The reason is as follows: if len is superior to SIZE, then p + len may overflow from the memory bound and wrap, thus resulting in a lesser value which will then be wrongly compared as lesser than limit. In the case of OpenSSL it could leads to decryption or encryption outside the assumed area (at the least).
    This is a good example showing that arithmetic overflow (and pointer arithmetic) must be considered carefully, especially when security is a concern,

References

1. https://www.openssl.org/blog/blog/2016/06/27/undefined-pointer-arithmetic/