Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of OpenSSL for pyca/cryptography

cryptography.io

Post reply on HN
Print view View original

31–40 of 65 posts

Re: The State of OpenSSL for pyca/cryptography

#31

Post by tptacek »

timschmidt wrote: post #28
PunchyHamster wrote: post #23

Earlier quoted context omitted.

I was surprised it is still in such bad state even after "rewrite" for 3.0.

I am not surprised at all, because instead of throwing their support behind the LibreSSL folks who audited the OpenSSL codebase after Heartbleed and found deep design and implementation issues, Linux Foundation and member orgs including most of Silicon Valley decided that OpenSSL just needed more funding. Felt like good money after bad on day 1.

The problem with the OpenSSL 3 codebase isn't security; many organizations, including the OpenSSL team itself, have been responsible for pulling out of the security rut OpenSSL was in when Heartbleed happened. The OpenSSL 3 problem is something else.

Re: The State of OpenSSL for pyca/cryptography

#32

Post by groby_b »

timschmidt wrote: post #28
PunchyHamster wrote: post #23

Earlier quoted context omitted.

I was surprised it is still in such bad state even after "rewrite" for 3.0.

I am not surprised at all, because instead of throwing their support behind the LibreSSL folks who audited the OpenSSL codebase after Heartbleed and found deep design and implementation issues, Linux Foundation and member orgs including most of Silicon Valley decided that OpenSSL just needed more funding. Felt like good money after bad on day 1.

And once you realize that Management + Finance + Marketing outnumber engineering at OpenSSL [1], you know the money is put to good use, too.

[1]: https://openssl-corporation.org/about/leadership/

Re: The State of OpenSSL for pyca/cryptography

#33

Post by timschmidt »

tptacek wrote: post #31
timschmidt wrote: post #28

Earlier quoted context omitted.

I am not surprised at all, because instead of throwing their support behind the LibreSSL folks who audited the OpenSSL codebase after Heartbleed and found deep design and implementation issues, Linux Foundation and member orgs including most of Silicon Valley decided that OpenSSL just needed more funding. Felt like good money after bad on day 1.

The problem with the OpenSSL 3 codebase isn't security; many organizations, including the OpenSSL team itself, have been responsible for pulling out of the security rut OpenSSL was in when Heartbleed happened. The OpenSSL 3 problem is something else.

[flagged]

Re: The State of OpenSSL for pyca/cryptography

#34

Post by timschmidt »

groby_b wrote: post #32
timschmidt wrote: post #28

Earlier quoted context omitted.

I am not surprised at all, because instead of throwing their support behind the LibreSSL folks who audited the OpenSSL codebase after Heartbleed and found deep design and implementation issues, Linux Foundation and member orgs including most of Silicon Valley decided that OpenSSL just needed more funding. Felt like good money after bad on day 1.

And once you realize that Management + Finance + Marketing outnumber engineering at OpenSSL [1], you know the money is put to good use, too. [1]: https://openssl-corporation.org/about/leadership/

If I were cynical, I'd think that the inscrutable code and resultant security issues were a feature desired by those management and finance types, not a bug. The purpose of a system being what it does, and all.

Re: The State of OpenSSL for pyca/cryptography

#35

Post by ForHackernews »

ameliaquining wrote: post #13
dfajgljsldkjag wrote: post #7

It is honestly surprising that OpenSSL has been the standard for so long given how difficult it is to work with. I think moving the backend to Rust is probably the right move for long term stability.

Note that all cryptographic primitives are still going to be in C via an OpenSSL-like API for the next while; the current proposal is to migrate from OpenSSL to one of its forks. Various bits of backend logic that aren't cryptographic primitives (e.g., parsing) have been rewritten in Rust; additionally, https://github.com/ctz/graviola is mentioned near the end as a possible implementation of cryptographic primitives…

Whatever happened to libsodium that was designed to provide vetted cryptographic primitives with a modern API? https://doc.libsodium.org/doc

Re: The State of OpenSSL for pyca/cryptography

#36

Post by rout39574 »

pseudohadamard wrote: post #29
nine_k wrote: post #25

Earlier quoted context omitted.

Are these edge cases correct to the spec, or not?

Yes. The spec is often such a confused mess that even the people who wrote it are surprised by what it requires. One example was when someone on the PKIX list spent some time explaining to X.509 standards people what it was that their own standard required, which they had been unaware of until then.

Got any links to that conversation? Sounds fun.

Re: The State of OpenSSL for pyca/cryptography

#37

Post by rurban »

some_furry wrote: post #30
captain_coffee wrote: post #19

I had no idea that OpenSSL is in such a bad state.

I took Rich Salz resigning from the project as a condemnation of its future, tbh https://mta.openssl.org/pipermail/openssl-users/2020-July/01...

He resigned over the non-removal of the "offensive" word master, not technical issues.

Re: The State of OpenSSL for pyca/cryptography

#38

Post by SAI_Peregrinus »

ForHackernews wrote: post #35
ameliaquining wrote: post #13

Earlier quoted context omitted.

Note that all cryptographic primitives are still going to be in C via an OpenSSL-like API for the next while; the current proposal is to migrate from OpenSSL to one of its forks. Various bits of backend logic that aren't cryptographic primitives (e.g., parsing) have been rewritten in Rust; additionally, https://github.com/ctz/graviola is mentioned near the end as a possible implementation of cryptographic primitives…

Whatever happened to libsodium that was designed to provide vetted cryptographic primitives with a modern API? https://doc.libsodium.org/doc

Still great, but the primitives it provides aren't necessarily the ones you need.

Re: The State of OpenSSL for pyca/cryptography

#39

Post by Macha »

PunchyHamster wrote: post #24
tialaramex wrote: post #15

Earlier quoted context omitted.

A couple of things probably made this more likely for OpenSSL than for other libraries, though I think this phenomenon (sticking with a famous library which just isn't very good) is overall just much more common than most people appreciate 1. OpenSSL is cryptography. We did explicitly tell people not to roll their own. So the first instinct of a programmer who finds X annoying ("Let's just write my own X") is ruled o…

but it isn't "rolling your own" but changing the lib you use. > The C++ programmer who needs to do an HTTPS POST but mostly is doing 3D graphics could spend a month learning about the Web PKI, AES, the X.500 directory system and the Distinguished Encoding, or they could just call OpenSSL and not care. they gonna call libcurl, not openssl directly. Tho they might use it still for parsing certs but that's easier to rep…

Pre all the recent OpenSSL forks the only other options were:

- use the platform sdks which have completely distinct APIs (and so probably aren't supported by everything between you and the TLS connection)

- Use GnuTLS which is GPL and so wasn't suitable for a lot of commercial uses (less important in the age of SaaS to be fair)

Re: The State of OpenSSL for pyca/cryptography

#40

Post by tialaramex »

Macha wrote: post #39
PunchyHamster wrote: post #24

Earlier quoted context omitted.

but it isn't "rolling your own" but changing the lib you use. > The C++ programmer who needs to do an HTTPS POST but mostly is doing 3D graphics could spend a month learning about the Web PKI, AES, the X.500 directory system and the Distinguished Encoding, or they could just call OpenSSL and not care. they gonna call libcurl, not openssl directly. Tho they might use it still for parsing certs but that's easier to rep…

Pre all the recent OpenSSL forks the only other options were: - use the platform sdks which have completely distinct APIs (and so probably aren't supported by everything between you and the TLS connection) - Use GnuTLS which is GPL and so wasn't suitable for a lot of commercial uses (less important in the age of SaaS to be fair)

Also, the platform SDKs invariably assume platform preferred semantics which might not be what you wanted if you write cross platform software.

In particular this means you get another source of platform difference, no only does your Windows App work with different peripherals from the Mac App (because of OS drivers), but now some certificates which work with the Mac App don't work in Windows or vice versa. OpenSSL lets you bundle your CA policies with the app and thus avoid that issue (though now it's your choice what is or isn't accepted and you're probably not ready for that labour)

Post reply on HN