from Hacker News

BearSSL – Smaller SSL/TLS

by ayrx on 11/3/16, 1:23 PM with 195 comments

  • by mythz on 11/3/16, 2:12 PM

    The last thing the world needs is another immature SSL/TLS implementation however this makes it very interesting:

    > No dynamic allocation whatsoever. There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.)

    > On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.

    Edit: Just discovered what makes this an even more interesting one to watch, it's the work of this Wizard: http://security.stackexchange.com/users/655/thomas-pornin

  • by bluejekyll on 11/3/16, 2:48 PM

    I love the idea of a zero allocation crypto library, but isn't the fact that this is also in C going eventually lead down a similar path as that of OpenSSL?

    I'm personally really excited for this: https://github.com/briansmith/ring

    It's a Rust oxidization of the BoringSSL library, meaning that parts of BoringSSL are being rewritten in Rust, with the eventual goal of being pure Rust.

  • by tptacek on 11/3/16, 3:57 PM

    Libraries like this are almost invariably a terrible idea: none of the more recent alternatives to OpenSSL I've seen have avoided resurrecting crypto bugs OpenSSL fixed years ago.

    But: Thomas Pornin!

    So, this is pretty neat. I hope lots of crypto people take a very hard look at it.

  • by rdeboo on 11/3/16, 1:53 PM

    One of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?

  • by savara on 11/3/16, 2:46 PM

    The page claims: "[...] insecure protocol versions and choices of algorithms are not supported, by design",

    followed by:

    "TLS 1.0, TLS 1.1 and TLS 1.2 are supported", "3DES/CBC encryption algorithms are supported", and "SHA-1 [is supported]"

    Sad-face.

  • by stompin on 11/3/16, 2:46 PM

    Given various clues such as: -"OS-less" -small memory footprint -going out of their way to include discussion of legal jurisdictions -the author and past activities -performance seems not a major concern

    Makes me suspect that a major goal is anonymity. It's less aimed at users installing on their non-anonymous Windows/Mac/phone but rather leverage generic/commodity hardware to communicate over SSL. Throwaway burner phones.

  • by diafygi on 11/3/16, 4:36 PM

    Oh man, can't wait for the docs. TLS 1.2 on an ESP8266 would make it possible to use them with AWS IoT.

  • by federicoponzi on 11/3/16, 3:08 PM

    I'm wondering why this isn't on github

  • by ncw33 on 11/3/16, 3:37 PM

    If Thomas has enough time to finish it (bearing in mind the hundreds of hours it will take to bring it to production quality) - and if he has time to maintain it over the years - and if he is able to commit to years' worth of future maintenance - then this could become a very nice and usable implementation.

    I think it's great when people write something for the love of it.

    For a high quality TLS implementation that is production-ready, and has had extensive third-party verification and certification, I'd recommend mbedTLS from ARM.

  • by israrkhan on 11/3/16, 6:18 PM

    Seems like it is trying to replace PolarSSL (now called mBed TLS). It even dervies the name from PolarSSL (Polar Bear). It is nice to have multiple options, however it can make the vulnerability management a nightmare. How many more SSL libraries do we need (OpenSSL, LibreSSL,S2N,GnuTLS), not to mention native SSL libraries (Secure Transport, SChannel)?

  • by conductor on 11/3/16, 9:40 PM

    @pornin

    Thanks, we definitely need a secure and reputable TLS implementation with small footprint for IoT devices.

    [invalid issue removed]

  • by client4 on 11/3/16, 4:41 PM

    I wonder if the Bear reference is in relation to the other smaller SSL implementation in WolfSSL https://www.wolfssl.com/wolfSSL/Home.html

  • by falcolas on 11/3/16, 2:29 PM

    An obvious dig at wolfSSL - I'd be curious to see a comparison between the two. wolfSSL appears to be the more mature of the two (which makes sense, it's been in use for over a decade, and has a business dedicated to its development).

  • by crb002 on 11/3/16, 2:06 PM

    Needs some Galois SAW tests. Also using OpenSSL for testing wouldn't be a bad idea.

  • by unwind on 11/3/16, 2:25 PM

    This sounded very interesting.

    However, it seems it's been developed "in secret" and the only public commit is a huge import of all of it. :/

    Too bad, the development history would have been very interesting to read, digesting it all at once is harder.

  • by bluefox on 11/3/16, 7:26 PM

    I've been reading the code for T0 (a FORTH->C thingy), and I arrived at the conclusion that C# is a terrible language. The code itself is nice and clean if you assume it, though.

  • by shove on 11/3/16, 4:06 PM

    finally might be able to handle SSL requests on memory-constrained Arduino / ESP-8266 projects?! Yes please!

  • by lisper on 11/3/16, 3:26 PM

    Another OpenSSL alternative:

    https://tls.mbed.org

  • by amluto on 11/3/16, 8:41 PM

    This could be an interesting code base to use in a kernel. It should just work.

  • by eganist on 11/3/16, 2:11 PM

  • by mtgx on 11/3/16, 3:10 PM

    Why bother with TLS 1.0 and TLS 1.1 anymore? I imagine by the time this project is "stable" Google would have already deprecated those two in Chrome.

    And 3DES?

    https://sweet32.info/

  • by nwmcsween on 11/3/16, 2:27 PM

    Please make a openssl compat api if possible, its incredibly hard porting n programs to $ssl.