Hacker News Reader

Comment by nicce | Hacker News Reader

In this case, the size might not give better security. OpenSSL is one the most tested products on the planet.

However, 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

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

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

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

I don't know anything, but chuckled because of today's news: https://news.ycombinator.com/item?id=33380500

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

Which of course doesn't affect libressl.

I still can't comprehend how the industry didn't simply move to libressl early on.

Being "one the most tested products on the planet" (citation needed, btw) did not prevent Heartbleed.

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

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

got any examples of this being used in popular FOSS software?

Depends 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/

[2] https://github.com/AbsInt/CompCert

[3] https://frama-c.com/

>all the time >not common >the cost That's what I thought... and seL4 was the only one I could think of as well. I always see arguments around auditing as well but I think realistically unless a project has some enormous resources capable of funding this things themselves, you can't expect it to happen, but so many people poo-poo projects simply because it's "not audited", but to me that's silly because 1. most projects can't afford that, 2. who gets to say what has been audited "well enough", and 3. auditing results are only valid for specific snapshots of a repo and are completely invalidated as soon as any new changes are made.

It does happen all the time in commercial contexts in certain industries. Look up Spark Ada for lots of commercials applications.

Nope, not even formal proofs can save you, see WPA2/KRACK.

Using proofs just shifts the bugs into the assumptions/axioms (i.e you think your proof is proving X but it's actually proving Y)

Given the lack of mention in the paper, I suspect they’re unable to distinguish OpenSSL from its forks, notably BoringSSL. OpenSSL might be used in an offline mode but I don’t think anyone really trusts it for online these days.

BoringSSL is more for client side tbf. It was built for Chromium.

It is not recommended to use for general parties, even Google does not recommend.

It was not built for chromium AFAIK

To quote: https://boringssl.googlesource.com/boringssl/

BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.

Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.

Can you clarify how you came to this conclusion? No idea about self-hosted stuff of course, but I'm pretty sure BoringSSL is one of the gold standards for the big cloud providers.

Counterpoints:

> Encryption Implemented in the Google Front End for Google Cloud Services and Implemented in the BoringSSL Cryptographic Library

https://cloud.google.com/docs/security/encryption-in-transit

> We use a common cryptographic library, Tink, which includes our FIPS 140-2 validated module (named BoringCrypto) to implement encryption consistently across Google Cloud

https://cloud.google.com/docs/security/encryption/default-en...

> It may (or may not!) come as surprise, but a few months ago we migrated Cloudflare’s edge SSL connection termination stack to use BoringSSL: Google's crypto and SSL implementation that started as a fork of OpenSSL.

https://blog.cloudflare.com/make-ssl-boring-again/

> We ported our SMTP server to use BoringSSL, Cloudflare’s SSL/TLS implementation of choice

https://blog.cloudflare.com/email-routing-leaves-beta/

> We are pleased to announce the availability of s2n-quic, an open-source Rust implementation of the QUIC protocol added to our set of AWS encryption open-source libraries. <snip> AWS-LC is a general-purpose cryptographic library maintained by AWS which originated from the Google project BoringSSL.

https://aws.amazon.com/blogs/security/introducing-s2n-quic-o...

This last one is not 100% clear but I would imagine AWS dogfoods their own encryption libraries to build their internal cloud stack.

Interesting, thanks for pointing put.

Reply on news.ycombinator.com