| OpenSSL | GnuTLS | |
|---|---|---|
| 174 | - | |
| 27,977 | 3 | |
| 1.6% | - | |
| 9.9 | 0.0 | |
| about 17 hours ago | about 14 years ago | |
| C | C | |
| Apache License 2.0 | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
OpenSSL
-
The Email Startup Graveyard: Why 80%+ of Email Companies Fail
> Electron Performance Crisis: Modern email clients built with Electron and React Native suffer from severe memory bloat and performance issues. These cross-platform frameworks, while convenient for developers, create resource-heavy applications that consume hundreds of megabytes to gigabytes of RAM for basic email functionality.
No (real) customer has ever, or will ever, care about this. Discord and Slack are pretty much case-in-points: bloated Electron apps that just about everyone on the planet has installed on their computers. I personally hate React, but technology decisions are irrelevant to the long-term success of startups. (As long as they don't grossly interfere with customer experience, the feature set, etc.)
> Final Warning: After analyzing hundreds of email startups, the evidence is overwhelming - 80%+ fail completely. Email isn't broken, and trying to "fix" it is a guaranteed path to failure.
First, I'd bet money that figure is actually wrong: the failure rate is likely way higher than 80%. And I'm honestly not sure how anyone could seriously think a 20% exit rate is bad in just about any vertical (but especially a "boring" one like email).
> Resources: Volunteer developers can't sustain enterprise-level software
What am I even reading here? Author does realize openssl[1], Linux[2], and many other "enterprise-level" pieces of software are entirely (or almost entirely) maintained by volunteer developers, right?
Anyway, the post had its opposite intended effect on me: it made me think about ways I could reinvent email.
[1] https://github.com/openssl/openssl
[2] https://github.com/torvalds/linux
-
I no longer have an old-school cert on my HTTPS site
> I don't really buy this explanation. It's a very large unsigned number. Everyone knows this.
Everyone knows that an RSA modulus is a very large unsigned number yes. Not everyone knows that every number is unsigned.
> Is there some arbitrary precision library in use that forces large integers to be signed?
OpenSSL's own BN (BigNum) library, which tests if the high bit is set in the input (line 482):
https://github.com/openssl/openssl/blob/a0d1af6574ae6a0e3872...
> Even if it were signed, or had the MSB set, it wouldn't change any of the bits, so the key would still be the same. So why would we care about the sign?
Because the encoding doesn't care about the context. RFC 3279 specifies that the modulus and exponent are encoded as INTEGERs:
https://datatracker.ietf.org/doc/html/rfc3279#section-2.3.1
... and INTEGERs are signed:
https://learn.microsoft.com/en-us/windows/win32/seccertenrol...
Integer values are encoded into a TLV triplet that begins with a Tag -
The State of SSL Stacks
Wow... reading this article in full really made me lose hope in OpenSSL, the project and the library.
I was well aware of the expected inconveniences any new major OpenSSL release would trigger (esp. older, less actively maintained applications having to adapt their API usage to keep working) going in, but what the linked github issue/PR comments hint at is just... mental.
As best illustrated by https://github.com/openssl/openssl/issues/20286#issuecomment... not only seem the core developers not care about runtime performance at all, they also seem to have a completely absurd perception of their own project, esp. in relation to other, genuinely small FOSS projects.
It's just wild. I hope this can still be turned around, and OpenSSL can somehow re-emerge from this clusterfuck as the stable bedrock of web transport security that we learned to rely on from 2014 onwards.
-
mTLS Authentication in Spring Boot Microservices
Generate Certificates: Use OpenSSL to create a Certificate Authority (CA) and server/client certificates.
- OpenSSL 3.5 [LTS] Released
-
HTTP/3 is everywhere but nowhere
Slow adoption of QUIC is the result of OpenSSL refusing to expose the primitives needed by QUIC implementations that already existed in the wild. Instead, they decided to build their own NIH QUIC stack, which after all these years is still not complete.
They recently caved in, and OpenSSL 3.5 will finally provide an API for third party QUIC stacks: https://github.com/openssl/openssl/pull/26683
Naturally, it works differently than all the other existing implementations, as it's push-based instead of pull-based. It remains to be seen what it means for the ecosystem.
-
Okta Bcrypt incident lessons for designing better APIs
In Node, you would commonly reach for the builtin core "node:crypto" module to run cryptographic functionality like this. I wondered why that wasn't used here, but bcryptjs was. After digging into it a little, node doesn't ship with core support for bcrypt, because it's not supported by OpenSSL.
The node crypto module is essentially an API that offloads crypto work to OpenSSL. If we dig into OpenSSL, they won't support bcrypt. Bcrypt won't be supported by OpenSSL because of reasons to do with standardisation. https://github.com/openssl/openssl/issues/5323
Since bcrypt is not a "standardised" algorithm, it makes me wonder why Okta used it, at all?
I remember in uni studying cryptography for application development and even then, back in 2013, it was used and recommended, but not standardised. it says a lot that 12 years on it still hasn't been.
-
The QUIC API OpenSSL will not provide
They pretty much told everyone that a proper integration for OpenSSL would take years. The server API seems to be in an early review state and slowly progressing.
https://github.com/openssl/openssl/tree/feature/quic-server
-
Encryption: ciphers, digests, salt, IV
The encryption used by default is AES256 and SHA256 hashing from the standard OpenSSL library, both of which are widely used in cryptography. You can however use any available cipher and digest (i.e. hash) that is supported by OpenSSL (even the custom ones you provide).
-
Curl removes experimental HTTP back end in Rust
Yeah, I'm using the curl wrapper crate for a Rust re-write of a C++ HTTP monitoring app I'm re-doing, because there's nothing I can find in the Rust ecosystem that even comes close to what libCurl exposes in terms of functionality and control (i.e. things like all the different timing numbers).
The wrapper crate hasn't got everything exposed for the Easy interface (I'll probably be submitting PRs to expose some missing stuff at some point), but seems good enough for me.
Only issue really I've found so far is that heap fragmentation seems orders of magnitude higher than the C++ version, and so memory useage grows quite alarmingly, but from heaptrack, that all seems to be from within openssl, with things like this (a rediculous number of heap allocations per request):
https://github.com/openssl/openssl/issues/14837
but I'm not sure why the C++ version doesn't suffer from the same issues as it's doing the same thing with HTTPS requests and is also using openssl, so I still need to look into that...
GnuTLS
We haven't tracked posts mentioning GnuTLS yet.
Tracking mentions began in Dec 2020.
What are some alternatives?
Crypto++ - free C++ class library of cryptographic schemes
mbedTLS - An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.
libsodium - A modern, portable, easy to use crypto library.
LibreSSL - LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code. Pull requests or patches sent to [email protected] are welcome.
GnuPG - Mirror of git://git.gnupg.org/gnupg.git — master branch contains no changes from upstream.