OpenSSL VS boringssl

Today, April 7th, 2024, marks the 10-year anniversary since CVE-2014-0160 was published. This security vulnerability known as "Heartbleed" was a flaw in the OpenSSL cryptography software, the most popular option to implement Transport Layer Security (TLS). In more layman's terms, if you type https:// in your browser address bar, chances are high that you are interacting with OpenSSL.

At this point I pretty much understand the entire process on how the xz backdoor came to be: its execution stages, extraction from binary "test" files etc. But one thing puzzles me: how can the ifunc mechanism be used to replace something like RSA_public_decrypt? Granted this probably stems from my lack of understanding of ifunc, but I was under the impression that in order for the ifunc mechanism to work in your code, you have to explicitly mark specific function with multiple implementations with __attribute__ ((ifunc ("the_resolver_function"))). Looking at the source code of the RSA function in question, ifunc attribute isn't present:

https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_crpt.c#L51

So how does the backdoor actually replace the call? Does this means that the ifunc mechanism can be used to override pretty much anything on the system?

OpenSSL and Go crypt/tls has no support yet, so none of the webservers that depend on them support it. Apache, Nginx, and Caddy, they all need upstream ECH support first.

- https://github.com/openssl/openssl/issues/7482

- https://github.com/openssl/openssl/pull/22938

- https://github.com/golang/go/issues/63369

If I'm understanding the draft correctly, I think the webserver you're hosting your sites on would need it implemented as it requires private keys and ECH configuration. In the example of nginx since it uses openssl, openssl would need to implement it. I found an issue on their Github but it's still open: https://github.com/openssl/openssl/issues/7482

I confirmed that the systm was on 1.1.1f with openssl version command. Hmm...... I check the openssl version in the repo with apt list... LOL package names wernt helpful. finally went to the repo pages and found that its still on 1.1.1f, https://launchpad.net/ubuntu/+source/openssl. Meenwhile I looked up the version history on https://www.openssl.org/ and saw that 1.1.1v was released at the beginning of this month... ok. I can understand it it was out less then 30 days. I looked up when f came out, end of MARCH 2020. NEARLY 3-1/2 YEARS

I have nothing constructive to add except that OpenSSL has a long history of producing vulnerabilities so much so that Google has created their own fork publicly available here: https://boringssl.googlesource.com/boringssl/ (used in chromium, chrome, and android).

> Large web companies like Google implement their own encryption stack anyway.

Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!).

So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs).

[1]: https://boringssl.googlesource.com/boringssl/

OpenSSL gets plenty of funding but we need to put more funding into TLS implementations that have a bigger focus on security and stability like boringssl, nss, go's tls, and rustls. It's 2022 and we have both languages better suited for this and tools to make existing languages safer and more robust, it's incredible to me that we aren't even more anxious over the current state of openssl.

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.

Use Google's fork of OpenSSL which exists because Google likes to do it's own weird things sometimes. This doesn't say anything about "OpenSSL is considered dangerous", it says "This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you."

And this is why projects like https://boringssl.googlesource.com/boringssl/ exist

The immediate effect of Heartbleed was the OpenBSD folk [1] and Google [2] forking OpenSSL.

There's a talk from Bob Beck of OpenBSD on pruning OpenSSL, it's pretty hilarious [3].

In that case open source was at least able to react appropriately, even if it didn't act preemptively.

[1]: https://www.libressl.org

[2]: https://boringssl.googlesource.com/boringssl/

[3]: https://www.youtube.com/watch?v=GnBbhXBDmwU

I doubt the reference to Musk's brand is intentional. It's more likely that it's a reference/homage to BoringSSL (https://github.com/google/boringssl) and "boring tech" in general that is purposefully designed to be minimalist, simple to use, and narrow in scope.