
BearSSL – Smaller SSL/TLS - ayrx
https://bearssl.org/
======
mythz
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](http://security.stackexchange.com/users/655/thomas-pornin)

~~~
saosebastiao
What sorts of applications are written for OS-less systems that require a TLS
library?

EDIT: Thanks for the sincere responses. In retrospect my question might have
appeared smarmy, but that wasn't my intent and I really appreciate the
responses.

~~~
StavrosK
I very badly need a TLS library in my embedded firmware so I can accept new
firmware updates over HTTP.

~~~
rthille
You don't need TLS for that, you could simply use an HMAC and a shared secret,
assuming you're not worried about people with physical access (and ability to
get the secret) being able to create updates. Of course if you've got multiple
instances of the device (not some hobby thing where they are all owned by
you), then the secret for each device should be different so someone can't buy
the device, determine the secret and then push updates to other people's
devices.

~~~
conradev
Wouldn't signing each release with a private key be the simplest solution
here?

(that can take many forms, but that general idea is how most software updates
currently work)

~~~
revelation
RSA means big integer which means unhappy performance on devices that often
don't even have floating point in hardware. I think elliptic curve could be
faster?

~~~
erichocean
> _I think elliptic curve could be faster?_

Yes, EdDSA is faster, with 64 byte signatures. Recommended.

[https://en.wikipedia.org/wiki/EdDSA](https://en.wikipedia.org/wiki/EdDSA)

------
bluejekyll
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](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.

~~~
lambda
> with the eventual goal of being pure Rust

No, being pure Rust is not the goal. It aims to use Rust as much as possible
for the parts that Rust is good at. But core crypto algorithms generally need
to be written in assembler, to avoid various timing attacks that could be
introduced by optimization. And for things that would require large amounts of
`unsafe` in Rust, there's less reason to port that to Rust, and leaving it in
C can be more clear.

See the style guidelines from the project:

[https://github.com/briansmith/ring/blob/master/STYLE.md#unsa...](https://github.com/briansmith/ring/blob/master/STYLE.md#unsafe)

The thing that are most appropriate for Rust are parsing, protocol
implementation, higher level code that uses core crypto primitives, and
providing a safe API to client code. But the core crypto primitives themselves
will remain written in C and/or assembler, as appropriate.

~~~
frutiger
> to avoid various timing attacks that could be introduced by optimization

Assembler only goes so far. Until you figure out how the processor's front end
will decode the machine code and run the underlying RISC program, or how the
hypervisor will schedule your program on some shared machines (e.g. in EC2)
you're susceptible to a different class of side-channel attacks.

~~~
tptacek
This is true but not relevant to the discussion: whatever side channel
problems you'd have in pure assembly, you're practically certain to have more
of them if you implement crypto in a high-level language with an aggressive
optimizer.

~~~
frutiger
Note I never disagreed with GGP's premise - I'm only pointing out that you can
go further than assembler.

~~~
bradleyjg
Is there any way to write programs that bypass the processor's front end for
most the processors in use? If not, it what sense is it true that "you can go
further than assembler"?

~~~
frutiger
You don't have much choice with commodity hardware - but you could perform
crypto on hardware/chips where the behavior is completely specified.

Note that this is not very practical, and impractical crypto is almost as good
as no crypto.

~~~
makomk
This is often, though not always, the case with deeply embedded processors of
the kind BearSSL seems to be designed for. There's generally some way to get
predictable cycle-exact performance on them because it matters for some
embedded applications.

------
tptacek
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.

~~~
jlgaddis
Yeah, the general wisdom is, basically, "if you don't know what you're doing,
leave the crypto to the experts".

I don't know the guy but, from what I gather, he is considered to one of these
experts, yes?

(Edit: If I would have read further comments before replying, I would've found
the answer to my question.)

~~~
Tomte
Besides being a crypto professor, he managed to guess what CRIME was about,
after it was announced that some bad OpenSSL advisory was imminent, but before
it came out.

Therefore the proposed bug squashing strategy of "just claim that there's a
bug in XYZ and let him oracle what it is".

------
rdeboo
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?

~~~
lexman0
Generally the cliche is about not implementing your own cryptographic
algorithms. As long as they only implement existing algorithms and don't
generate new ones, I don't think this applies.

~~~
rdeboo
I used to think that; but I'm following Dan Boneh's crypto course on Coursera
at the moment, and he specifically notes that you should not even try to
implement known algorithms yourself (for production; you could do it ofcourse
for the learning experience).

The reason is that there are subtle attacks on the implementation, such as
timing attacks, which can leak information.

~~~
mSparks
cant be any worse than openssl.

they have all code running in constant time from the alpha version.

Next comes making sure there are no buffer overflows. the code is stable and
compatible.

If everyone leaves it to someone else who does it exactly?

Obviously not ready for use in production until its been audited.

Remind me again where i can download an audited ssl implimentation?

~~~
BillinghamJ
> cant be any worse than openssl.

Not sure I'd agree with that. OpenSSL is very far from perfect and obviously
contains many many security bugs, but it also has a very long history of
fixes, knowledge, etc. and has a large number of eyes on it. It's more of a
known quantity than something new.

~~~
wbl
OpenSSL does not have half the fixes people think it does. Generally what gets
fixed is the ciphersuites some people happen to use, and the rest remain
broken. For example, the constant time ECDSA signing only works with some
curves, not all. It still supports horrific hacks for random number
generation, instead of using OS provided interfaces. NSS is not much better on
this front, but does a far better job of parsing TLS records in a sane way.

------
savara
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.

~~~
DasIch
There is not supporting insecure protocols and then there is living in fantasy
land away from everyone else.

You can't drop all of these things and end up with something generally useful.

~~~
savara
Sure, I agree -- but that's not what the page claims. It says "insecure
protocol versions and choices of algorithms are not supported, by design" \--
the protocols and modes that I listed are known to have various insecurities,
and it still supports them. I agree that to be useful it's necessary to
support old, less secure or even insecure modes, but this is at odds with the
above stated goal.

My point is about the imprecise description.

~~~
DasIch
You're right technically but don't you think that's a little bit pedantic?

If your goal is to truly improve the state of the art in the ecosystem,
dropping anything that is even remotely insecure is appealing I get that and I
do believe the people behind BearSSL would love to do that. However to truly
improve anything you need two things: Popularity and improve security.

There is a conflict there because popularity requires, at least some,
compatibility to what already exists. You need to balance out security and
compatibility. I think there is room for discussion about where precisely that
balance is. You could further tilt it towards security by helping users of the
library get a sense of what they need to support. Ultimately though you can't
just blindly drop everything that's somehow not perfectly secure. Doing so
would not improve security at all.

It's a small sacrifice to have one library be a little bit less secure than it
could be, if that helps to make everything more secure it all.

------
stompin
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.

~~~
DasIch
This just looks like someone who is aware of the complex legal history
associated with cryptography and has considered embedded devices in the design
of the library.

Considering the recent events around IoT having good crypto libraries for that
seems like it could be useful.

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

~~~
bschwindHN
From what I understand, you _can_ use them already with AWS IoT but I'm not
sure if this solution is ideal or secure enough. Haven't used it personally
but it's there:

[https://github.com/SuperHouse/esp-open-
rtos/blob/master/exam...](https://github.com/SuperHouse/esp-open-
rtos/blob/master/examples/aws_iot/README.md)

------
federicoponzi
I'm wondering why this isn't on github

~~~
pornin
I wanted a clear situation with regards to laws on cryptographic software
distribution and export. With my own server, I can keep everything in Canada,
which makes things simpler.

~~~
euyyn
Why not run Gitlab on that server?

~~~
dchest
It's hard to get by without all the fancy CVE features in GitLab, but software
written in Ruby on Rails is banned in Canada, so they had to use good ol'
reliable gitweb.

~~~
mSparks
->Rails is banned in Canada...

wohaa. what?

wow. an opportunity for me to use google. if you are actually serious?

edit:lol my phone default searches to bing... didn't find anything about ruby
on rails being banned in canada.

~~~
new_hackers
haha, I did the same thing. Must be trolling, or sarcasm

------
ncw33
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.

------
israrkhan
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)?

~~~
byuu
We need a crypto library that is easy to use in other applications that want
security.

This trainwreck of an API is the opposite of what we want:
[https://gnutls.org/reference/gnutls-
gnutls.html](https://gnutls.org/reference/gnutls-gnutls.html)

It would probably be faster to write your own TLS library than learn all of
that.

OpenSSL doesn't fare much better. So far, libtls looks the most promising. But
last I checked, it was still a bit _too_ spartan and couldn't operate in non-
blocking mode, which kills you if you want an event-driven server.

~~~
niftich
I, for one, am still waiting for the TLS library that's the spiritual
equivalent of NaCl or libsodium; where the integration surface is narrowed to
the essentials, and sensible and secure (internal) defaults predominate.

------
conductor
@pornin

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

 _[invalid issue removed]_

~~~
tomlogic
q starts out larger than len, but is decremented inside the inner for loop.

~~~
conductor
Thanks, it seems the separate from variable decrease operator (q --) broke my
"internal parser" as I completely missed it somehow. I'll edit my post to
remove the noise.

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

~~~
raesene2
The bear is more a favourite animal of the author

------
falcolas
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).

~~~
ayrx
Not quite, Thomas's avatar in many places is that of a bear. He has named a
few of his works after bears, in particular his password hashing function
Makwa.

~~~
falcolas
I'll admit, they're a local company that I have a fair bit of respect for, so
I'm a bit protective about people attacking them. That said, BearSSL is just
too close to be coincidence.

The author could have easily continued with their trend of using alternative
languages and ended up with something just as unique. UrsidSSL, BhaalooSSL,
XiongSSL; all could have continued the trend without coming across as a sly
attack.

It's not as if wolfSSL is a new kid on the block in the world of embedded SSL.

~~~
mythz
It has nothing to do with WolfSSL, Thomas uses a Bear as his avatar, done.
I've never heard of WolfSSL, but Thomas's name and avatar was instantly
familiar as someone who's contributed a wealth of invaluable Crypto knowledge
to the world.

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

------
unwind
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.

~~~
pornin
Honestly, all my internal git commit messages are "...".

I intend to write (in many details) how the whole thing is designed. Give me a
couple of months.

~~~
unwind
Okay, that explains it, anyway. :)

I have absolutely nothing to say when it comes to crypto, but as a C dork I
found it ... quirky that the encoding/decoding functions in inner.h
([https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/inner.h;h...](https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/inner.h;h=9edaadd1ffc799655830e87f0d77b447e58d934d;hb=HEAD))
seem to use e.g. uint32_t to get a 32-bit type, while assuming that char is 8
bits (rather than using uint8_t). This seems strange.

~~~
zAy0LfpBZLC8mAC
I don't think it assumes it's 8 bits, but rather it assumes the values won't
be outside the range of an 8 bit number, which should be fine, given that it's
an octet-oriented protocol?

Using char pointers presumably is to get correct aliasing analysis?

------
bluefox
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.

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

------
lisper
Another OpenSSL alternative:

[https://tls.mbed.org](https://tls.mbed.org)

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

------
eganist
Edit: [http://www.bolet.org/~pornin/cv-
en.html](http://www.bolet.org/~pornin/cv-en.html)

Disregard me.

~~~
drzaiusapelord
Says who? Maybe the cruft of the old ones means its impractical to fix. Maybe
the leadership of the old ones means it can't be fixed due to incompetence or
toxic politics. Sometimes rolling your own or forking is the smart move.
There's a reason you use x.org and not xfree86 for example.

The idea that no one should ever roll their own cryptography is a cutesey
warning for amateurs, but not an absolute rule. If no one ever did, we would
never have any.

Also projects like openssl don't have third-party quarterly audits or other
formal practices. They're "rolling their own" as much as the other guy.

~~~
eganist
Doesn't matter anymore -- the credibility of the person leading the project is
thoroughly established, so I'm retracting my comment.

But generally, "says who" is answerable as "says any reputable applied
cryptographer, established audit/research team, etc. who's thoroughly cut
their teeth on crypto and security in general."

------
mtgx
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/](https://sweet32.info/)

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

~~~
dimman
No really he should not. A separate translation layer is free for anyone to
write though. The OpenSSL design from an API perspective is basically as far
from "user friendly" as possibly possible. Having a hard-to-use API means that
it's hard to get things right. If things are hard to get right it leads to
more bugs. You get where I'm going with this.

A clean, simple to use, or rather hard-to-use-in-a-wrong-way API is very much
needed (and there are some libraries that are nice to use but not very
proven).

~~~
nwmcsween
I don't really know what you mean about a hard-to-use api as openssl compat
would just wrap the bearssl api and not make any difference to consumers of
bearssl.

~~~
fdr
The problem is that OpenSSL's API itself is quite complicated and probably not
in an entirely necessary way. As but one concrete example, there's almost no
particularly satisfying way to handle the "error queue" in a world with
imperfect software. I also recently found how how insanely impractical it is
in practice to perform one's own certificate validation (e.g. so I could
interpret the CN field) if a TLS connection is abstracted even a tiny bit
(e.g. in a database driver).

Little doubt that someone would find it useful, but it is An Undertaking, to
preserve something which is not that desirable.

