OpenSSL VS cryptography

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

Congratulations to the authors, this was a feature that was dearly missing from pyca/cryptography. It took a long time to get right.

For the history: https://github.com/pyca/cryptography/issues/2381

Some context:

- The cryptography dependency used by the current release of mitmproxy has a CVE related to an OpenSSL vulnerability (https://github.com/pyca/cryptography/security/advisories/GHS...)

- The main branch of mitmproxy has already upgraded to the latest version of the cryptography package

- The author of the package does not believe the CVE impacts users of mitmproxy so a release including this commit has not been made

Also you'll use https://github.com/pyca/cryptography

first, I did see a correlation between an endpoint being heavily hit in a given time window, and an increase of memory usage that didn't went down afterwards. The endpoint didn't do much so I went through every instruction - is a global variable appended indefinitely ? Is a cache decorator growing without a limit set ? Do I use a 3rd party that has a known issue ? Turns out, it was using cryptography, so I looked up known issues. Saw an issue about a leak when using load_pem_x509_certificate https://github.com/pyca/cryptography/issues/4833 - which I used ! I could fortunately just upgrade the library

Après le kerfuffle du paquet de cryptographie cette semaine (https://github.com/pyca/cryptography/issues/5771), J’ai passé en revue l’état des outils de gestion des dépendances en Python.

> A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs.

One thing this is missing is that Rust is useful for libraries callable by many different languages. You may or may not want to use it to build an actual Web app (I personally think it's a solid choice, but reasonable people can disagree). But for building, say, the Python cryptography library [1], which is used as a part of "webcrap" and Jupyter notebooks, Rust is clearly an excellent option. Nobody is going to build core Python infrastructure in Go or Node, and there will always be a need for plumbing libraries.

[1]: https://github.com/pyca/cryptography

Also, I see more and more examples where rust gets included in different technologies using FFI. Ie for python https://github.com/pyca/cryptography for security/performance critical pieces.

> I am curious. Could you give some more context?

Probably talking about this: https://github.com/pyca/cryptography/issues/5771

You will be hard pressed to find a cryptography library that doesn't depend on openssl. Fortunately openssl bindings can be installed on Windows. One of the more popular libraries for python is cryptography, but it does depend on libssl.