6 ms·
BearSSL: A smaller SSL/TLS library
- mro_name 4y agois there a tutorial how to run bearssl on lighttpd/devuan.org and achive good marks in ssllabs.com/ssltest?
- robalni 4y agoInteresting to see BearSSL mentioned today because I have just started to replace OpenSSL with BearSSL in my webserver. The reason for that is that the server and the computer I develop on run different versions of Debian that have different versions of OpenSSL, so the server suddenly stopped working because the program linked dynamically to a newer version of OpenSSL that the server didn't have. I tried to link OpenSSL statically but at that point i thought it was better to move to BearSSL.
- yjftsjthsd-h 4y agoHow does that help? Unless bearssl has a perfectly stable api aren't you just trading one library for another?
- robalni 4y agoIf I'm going to link statically, I prefer a smaller library, both for size and security reasons. I was also getting some issues when linking OpenSSL statically and I think (or hope) that will be easier to do with BearSSL.
- nicce 4y agoIn this case, the size might not give better security. OpenSSL is one the most tested products on the planet.
- snvzz 4y agoEyes on the code help find bugs. Smaller code helps prevent bugs, as there's simply less code where bugs could be. Thus it is not as clear as you picture it. What is clear, however, is that it should be easier to make BearSSL's code bug-free, by virtue of having less code.
- nicce 4y agoThis is true. But BearSSL does not have so many eyes on looking it, nor haven’t had the same duration as OpenSLL have had. Which makes it complicated.
- raesene9 4y agoHowever, it is also complex and has been worked on by many people which increases the chances of bugs due to mis-understandings between team members. In contrast BearSSL is kept simple, and is primarily the work of a single author, who knows a lot about cryptography
- nicce 4y agoThere are pros and cons always. But it is not good either if there is only one primary developer. There is a high risk that single author becomes blind for is own bad coding practices, if there are some, and they will repeat. It is also difficult to understand every possible use-case alone.
- tremon 4y agoBeing "one the most tested products on the planet" (citation needed, btw) did not prevent Heartbleed.
- nicce 4y agoNo software can be quaranteed to be bug-free. And Heartbleed bug was in the extension, not in the core software. > (citation needed, btw) Not really. But if you insist, OpenSSL is defacto crypto library [1] , at least on server side. Browsers and OpenSSL takes the most burden for securing every-day use of internet in the world. There are billions testers every day. [1] : https://crocs.fi.muni.cz/public/papers/acsac2017 https://crocs.fi.muni.cz/public/papers/acsac2017)
- naasking 4y ago> No software can be quaranteed to be bug-free. Sure, this is done all the time via verification and other formal methods. It's not common in the industry, but not entirely uncommon either.
- ranger_danger 4y agogot any examples of this being used in popular FOSS software?
- naasking 4y agoDepends what you mean by "popular". seL4 [1] is formally verified, open source and is used as baseband firmware in millions of phones, among other uses. Google just recently started an embedded OS based on it as well. CompCert [2] is a formally verified optimizing C compiler. Most formal verification happens in compilers or low-level mission critical systems due to the cost. If you want to write some formally verified C, you can check out Frama-C [3]. [1] https://sel4.systems/ https://sel4.systems/ [2] https://github.com/AbsInt/CompCert https://github.com/AbsInt/CompCert [3] https://frama-c.com/ https://frama-c.com/
- raro11 4y agoI don't know anything, but chuckled because of today's news: https://news.ycombinator.com/item?id=33380500 https://news.ycombinator.com/item?id=33380500
- nicce 4y agoImpact of the bugs in OpenSSL are so significant, that they always end up in to the news. BearSSL is still a quite little project compared to it, and because of that no CVE:s are being made if the author finds a bug by themself from his own code. On the other hand, every bug in OpenSSL gets CVE mark and will end up into the news. It gives distorted view and comparison of the software quality between many projects.
- snvzz 4y agoWhich of course doesn't affect libressl. I still can't comprehend how the industry didn't simply move to libressl early on.
- rurban 4y agoFor example BearSSL uses constant-time algorithms, openssl not. BearSSL GHASH is still fast whilst secure, openssl AES not.
- blackflame7000 4y agoAES is used for encryption while GHASH is a hash(checksum) algorithm. Quite different. Also the algo time is a function of the input size. Not sure how you can encrypt 1byte and 2TB in constant time. You seem like you need to read more on this stuff.
- MarceColl 4y agoMaybe you need to read more on this stuff: https://www.bearssl.org/constanttime.html https://www.bearssl.org/constanttime.html
- blackflame7000 4y agoRSA has been deprecated for a while. It still has nothing to do with the fact that you compared a hashing algorithm with a symmetric encryption algorithm, a literal apple to orange comparison
- MarceColl 4y agoFirst, I'm not the parent, I didn't compare a thing. Second, that page has information on a lot of crypto algos and not only on RSA so I don't know what you are talking about.
- MrBuddyCasino 4y agoSaved my ass on an embedded project years ago, when I couldn’t spare a few KB for the TLS buffers. Great library, well designed.
- userbinator 4y agoNo dynamic allocation whatsoever I think this alone is an excellent reason to study the code, but only after you've already had a mental exercise of considering how you could write such an implementation without any dynamic allocation. One of the things that I've noticed in a lot of codebases is superfluous dynamic allocation, which can often be eliminated to make things simpler, more efficient, and removes a possible error-path.
- peter_d_sherman 4y agoExcellent point!
- als0 4y agoI think MbedTLS requires a memory allocator, which if true then BearSSL seems quite attractive. At least for simple scenarios. The advantage of MbedTLS is that it's starting to have more support for hardware accelerators.
- berkut 4y agoIs this still under active development? I looked at this two years ago, and it didn't have TLS 1.3 support, so I went with openssl and have replaced that with s2n (which uses bits of openssl under-the-hood) last year for some things. The features page looks like TLS 1.3 still isn't supported, and the git changelog doesn't show much happening...
- tialaramex 4y agoI expect that the focus on size constraint means this attracts a lot fewer "Hey, here's a cute thing somebody might want" changes, it also means the skillset needed to contribute at all is probably more demanding, if you're used to just calling malloc() whenever you need somewhere to keep a structure this project doesn't want your code.
- stefan_ 4y agoI think TLS 1.3 has some "features" that essentially take a giant dump on trying to make them work in a resource constrained, no dynamic allocation environment. That might have blunted the enthusiasm to work more on it.
- jart 4y agoI've been using MbedTLS which is a similar project and loving it. But the last time I looked at the BearSSL code, it was very clean and beautiful in a way that MbedTLS isn't. Does anyone here have experience with both libraries who could illuminate the tradeoffs? For example, does BearSSL have TLS 1.3? I'd be willing to give up all previous versions of TLS just to have 1.3. I want it so badly I'm about to implement it into MbedTLS myself.
- harryvederci 4y agoBy now, you saying you're about to implement something yourself is probably an indicator for everyone else that they don't have to do it. "We're good, everyone. Justine is on it."
- jart 4y agoHeh. In the Cosmopolitan documentary there's a scene where all these other animals just stand around waiting for the honey badger to find food before diving in. https://youtu.be/chtdRCrZKuw?t=247 https://youtu.be/chtdRCrZKuw?t=247
- tialaramex 4y agoNot yet. https://bearssl.org/tls13.html https://bearssl.org/tls13.html Also, Bear is unlikely to do e.g. 0-RTT which might be a TLS 1.3 feature you really wanted unless you just "want it so badly" because it's a bigger number.
- jart 4y agoThose aren't very compelling reasons for me to not be allowed to serve cat photos with better latency. Looks like BearSSL doesn't share my values.
- pclmulqdq 4y agoInteresting reasons. TLS has always been weak to a few classes of attacks (historically both MITM and replay attacks), but these developers are taking that weakness very seriously. Also, most HTTP requests are idempotent, which is going to be the use case of 99% of people. The other two reasons they give are about abstractions that they defined for themselves. The idea of buffering 0-RTT requests is also kind of silly, and completely untenable if you want to avoid memory waste.
- deleted 4y ago[deleted]
- synergy20 4y agogreat project but it is inactive for a few years
- water8 4y ago
- hannasm 4y agoThis has worked well enough for an Arduino IoT project. Small footprint and acceptable performance. I think it comes recommended by the chip manufacturer or vendor.
- tssva 4y agoThere is a port to the esp8266 which is used as the TLS library for the esp8266 Arduino core.
- ape4 4y agoI just tried it. It was very nice. It compiled with a simple `make` and there were no errors or warning (on Linux). There are few test programs that seem to work.
- alberth 4y agoDumb question: why would someone use an alternative library for something as important as encryption?
- gumby 4y agoAssuming it has good functionality: it will have different bugs from the “other package”. So if someone finds a vulnerability in the other pkg your system won’t be vulnerable. And/or you want specific functionality, like the lack of dynamic allocation. Monoculture is a dangerous trap.
- RealStickman_ 4y agoBecause OpenSSL also has bugs. https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/news/vulnerabilities.html
- castillar76 4y agoIn addition to the bug issue, OpenSSL has been around a long time and has accumulated a great deal of extra bits and bobs due to it being the Swiss-Army Knife of encryption on a lot of systems. If you’re writing a webserver, you’re unlikely to need support for, say, S/MIME for email encryption, but it’s in there. Smaller libraries like Bear or Boring that were designed specifically to do TLS and little else don’t have the extra pieces, which reduces attack surface, simplifies the code, and makes it easier to remove old encryption ciphers and add new ones.
- mro_name 4y agothere isn't an automatic, global, eternal best choice just because a topic is important.
- jron 4y agoIs BearSSL still maintained? It looks like it hasn't been updated in almost 4 years.
- jansommer 4y agohttps://bearssl.org/gitweb/?p=BearSSL;a=summary https://bearssl.org/gitweb/?p=BearSSL;a=summary
- silisili 4y agoI owe probably 50% or more of what I've learned about crypto and TLS to Thomas Pornin. He's extremely bright, used to be(and may still be) super active on SE, and one of the few people who both understands it well enough to speak in specifics, but does so freely. I'd absolutely trust anything he writes.
- teddyh 4y agoDoes it support RFC 7250 (Raw Public Keys)? I can’t easily tell.
- pkrumins 4y agoWe’re trying this in production right now for our tunneling feature. So far looks very promising!
- korginator 4y agoBeen using BearSSL in side projects on and off, and it's an excellent little library. That said, I use MbedTLS for production work on embedded hardware because it just integrates better with the other bits and pieces of code, and often comes as part of the platform SDK itself or has been tested with the platform. This plays a big part in getting people to use it.