OpenSSL VS cfssl

> 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

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.

Generate Certificates: Use OpenSSL to create a Certificate Authority (CA) and server/client certificates.

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.

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.

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

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).

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...

HTTP/3 support is a bit frustrating, since it's highlighted a serious split in engineering effort & focus, which has created a two-tier internet: browsers & big CDNs do support and use HTTP/3 heavily, but most small tools, servers and programming languages don't have stable built-in support at all (e.g. no support in the standard libraries for Go, Node.js, Python, etc) for either clients or servers. Even big tools like Nginx only have experimental support, disabled by default: https://nginx.org/en/docs/http/ngx_http_v3_module.html

Many years after this article was posted, OpenSSL does now have QUIC _client_ support (from 3.2: https://github.com/openssl/openssl/blob/master/README-QUIC.m...) but server support is still not available (and for Node at least, OpenSSL's approach here has been one of the main blockers for serious built-in HTTP/3 support).

There are some native libraries you can use to work around this, but they're not easy to set up in many cases and they're totally separate from each languages normal network stack. As a typical developer, the general solution is still 'just use HTTP/2 everywhere', even as HTTP/3 use on the browser web spikes higher and higher.

cfssl is kinda outright better version of that.

The Cloudflare SSL tools at https://github.com/cloudflare/cfssl might help. Here's what it shows for one of the example Snake Oil certs:

I've used this in the past and it worked great. https://github.com/cloudflare/cfssl

The first step is to create the source key that represents our user. This key is created using a tool like openssl but another popular tool to use is cfssl, created by Cloudflare. Some folks think cfssl is easier to use, and it definitely looks easier to script. But for this example we will use openssl. You can also choose to create the key using a number of different algorithms. For this example we will use ED25519.

TLS/SSL worked well with client certificates generated by the CFSSL API.

Not sure if relevant but we used tooling from CloudFlare in the past: https://github.com/cloudflare/cfssl