3 ms·

I'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

by jart 4y ago

I'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 ago
By 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 ago
  Heh. 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 ago
Not 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 ago
  Those 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 ago
  Interesting 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]
10000truths 4y ago
Two strong points for BearSSL: - Its sans-I/O design. Too many networking-related libraries out there mix the protocol state machine logic and the I/O. In doing so, they impose a certain style of I/O and make it impossible to integrate with an existing event loop, unless you’re willing to sacrifice scalability by spawning a thread+semaphore for each connection. I’d love it if I could use libssh2 or libmysqlclient’s state machine with io_uring or DPDK! Other TLS libraries do have stuff like memory BIOs, but they’re managed by the library and force an extra memory copy to get your data to its final destination. - No mutable global state. The fact that all functions are fully reentrant means that it’s easily usable in an interruptible context, common in freestanding environments or runtimes with fibers/coroutines. The tradeoff is that it lacks TLS 1.3 and DTLS support. The latter in particular is something I look forward to so that a QUIC state machine in C is possible.
- simon04 4y ago
  > TLS 1.0, TLS 1.1 and TLS 1.2 are supported. By design, SSL 2.0 and SSL 3.0 are not supported. TLS 1.3 isn't mentioned.
ranger_danger 4y ago
mbedtls just recently got 1.3.

by jart 4y ago

harryvederci 4y ago

By 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 ago
Heh. 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 ago

Not 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 ago
Those 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 ago
Interesting 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]

10000truths 4y ago

Two strong points for BearSSL: - Its sans-I/O design. Too many networking-related libraries out there mix the protocol state machine logic and the I/O. In doing so, they impose a certain style of I/O and make it impossible to integrate with an existing event loop, unless you’re willing to sacrifice scalability by spawning a thread+semaphore for each connection. I’d love it if I could use libssh2 or libmysqlclient’s state machine with io_uring or DPDK! Other TLS libraries do have stuff like memory BIOs, but they’re managed by the library and force an extra memory copy to get your data to its final destination. - No mutable global state. The fact that all functions are fully reentrant means that it’s easily usable in an interruptible context, common in freestanding environments or runtimes with fibers/coroutines. The tradeoff is that it lacks TLS 1.3 and DTLS support. The latter in particular is something I look forward to so that a QUIC state machine in C is possible.

simon04 4y ago
> TLS 1.0, TLS 1.1 and TLS 1.2 are supported. By design, SSL 2.0 and SSL 3.0 are not supported. TLS 1.3 isn't mentioned.

ranger_danger 4y ago

mbedtls just recently got 1.3.