BearSSL – Smaller SSL/TLS • Hacker News Board

Re: BearSSL – Smaller SSL/TLS

#151

Post by usefulcat » Thu, Nov 03, 2016, 8:49 PM UTC

sigjuice wrote: post #142

usefulcat wrote: post #119

Earlier quoted context omitted.

Not using the heap != everything is allocated on the stack. In situations where you want to avoid dynamic allocation, memory for most things that would otherwise have been dynamically allocated ends up being statically allocated at compile time.

Absolutely none of this is immune to buffer overflows.

No, but you're a lot more likely to be able to overwrite the return address via a stack-based buffer overflow, and that is generally a much more serious kind of attack.

Re: BearSSL – Smaller SSL/TLS

#152

Post by byuu » Thu, Nov 03, 2016, 8:53 PM UTC

savara wrote: post #53

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.

You kind of have to support SHA-1 still. Even with the browsers moving to deprecate it, many of the root certificates valid for another 10-20 years are still using it. (since the root certs ship with the browser, the security risk is lessened.)

If this is to be a general library that validates the entire certificate chain, then you'll need SHA-1.

Now if the library tries to advertise SHA1 in ServerHello by default, then that is indeed unfortunate.

Re: BearSSL – Smaller SSL/TLS

#153

Post by new_hackers » Thu, Nov 03, 2016, 8:56 PM UTC

mSparks wrote: post #144

dchest wrote: post #118

Earlier quoted context omitted.

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.

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

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

Re: BearSSL – Smaller SSL/TLS

#154

Post by new_hackers » Thu, Nov 03, 2016, 8:58 PM UTC

client4 wrote: post #103

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

I first thought of PolarSSL, and thought there must be a connection there. (hmm apparently is now renamed to mbed TLS)

Re: BearSSL – Smaller SSL/TLS

#155

Post by byuu » Thu, Nov 03, 2016, 9:00 PM UTC

israrkhan wrote: post #125

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

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

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.

Re: BearSSL – Smaller SSL/TLS

#156

Post by frutiger » Thu, Nov 03, 2016, 9:02 PM UTC

bradleyjg wrote: post #145

frutiger wrote: post #141

Earlier quoted context omitted.

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

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

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.

Re: BearSSL – Smaller SSL/TLS

#157

Post by niftich » Thu, Nov 03, 2016, 9:06 PM UTC

byuu wrote: post #155

israrkhan wrote: post #125

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

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 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 opera…

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.

Re: BearSSL – Smaller SSL/TLS

#158

Post by baby » Thu, Nov 03, 2016, 9:15 PM UTC

conradev wrote: post #124

rthille wrote: post #121

Earlier quoted context omitted.

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 secre…

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)

Yup you are right.

Re: BearSSL – Smaller SSL/TLS

#159

Post by baby » Thu, Nov 03, 2016, 9:16 PM UTC

pornin wrote: post #6

rdeboo wrote: post #2

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?

It is a combination of "many eyes" and "good documentation". What is needed is some good text that describes the design choice, the rationale, and all the tricky details; and then people who read it and think about it. I'll write and publish such text within the next few months.

any RSS feed to be able to catch that?

Re: BearSSL – Smaller SSL/TLS

#160

Post by Matthias247 » Thu, Nov 03, 2016, 9:33 PM UTC

throwaway2016a wrote: post #105

tdb7893 wrote: post #101

Earlier quoted context omitted.

probably could be useful in some small "internet of things" device

This. Internet of Things especially can benefit from adding TLS.

However you would often want DTLS there, which is for example what CoAP (HTTP-like IoT protocol which is based on UDP) uses.