cryptography VS OpenSSL

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

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

> 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

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

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

As for an example, cryptography is the general example I recommend here: https://github.com/pyca/cryptography

Wasn't entirely serious, just this crap https://github.com/pyca/cryptography/issues/5771

The modes of operation aren't the main reason people use OpenSSL; it's the support for all the gnarly (and less gnarly) protocols and wire formats that show up when doing applied cryptography.

Progress is being made on replacing OpenSSL in a lot of contexts (specifically, the RustCrypto[1] folks are doing excellent work and so is cryptography[2]), but there are still plenty of areas where OpenSSL is needed to compose the mostly algebraic cryptography with the right wire format.

[1]: https://github.com/RustCrypto

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

2) Which cryptographic library would be recommended for this purpose? I've seen people using PyCrypto (https://github.com/pycrypto/pycrypto) which seems simple enough, but that one seems not maintained anymore. I've also seen keyring.cryptfile (https://github.com/frispete/keyrings.cryptfile) and pyca/cryptography (https://github.com/pyca/cryptography) but I'm not really sure if any of those should actually be used for my purpose?

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.

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

Source code: https://github.com/openssl/openssl/blob/master/crypto/aes/aes_core.c

Ah, I see, OpenSSL is licensed under apache[1], so they can distribute patches under non-OSS licenses. I thought it was GPL for some reason.

1: https://www.openssl.org/

thanks, and what is the reason git clone -b openssl-3.1 https://github.com/openssl/openssl cloned the 3.1.0-dev and not just 3.1.0? Because that's just how they named the branch - 3.1, and not 3.1.0?

==> Downloading https://github.com/openssl/openssl/commit/96f1dbea67247b79b1e7b3

I understand that it looks that way, especially since I just noticed you're a C++ developer who's been trying to learn it recently. But really, when on one hand you have a critical CVE caused by one wrong byte of C source code and on the other hand you have net zero memory-related CVEs in ~1.5 million lines of Rust code compared to 1 CVE per 1k SLOC in their C++ codebase, there's no denial that Rust simply does have the safety advantage for that kind of low level development. Heck, as I always say, memory safety is not a new concept at all, garbage-collected languages have had it for several decades now. But garbage-collected languages weren't fit for projects like the Linux kernel or drivers (at least I assume that is the case), which is why such a thing is exciting and good news in the first place.