TLS Performance: Rustls versus OpenSSL
jbp.ioWhile I'm happy to see such progress, this ultimately doesn't say a lot. Openssl is known questionable code, and more or less is known for its kitchen sink and ubiquitousness, which I presume rustls(wisely) avoided. That said, I'd be interested to see a feature breakdown, but also put up against others like boring, polar, libre, etc.
Don't boringSSL & libreSSL have pretty much feature-parity with openSSL besides legacy and deprecated ciphers/features since they are forks of openSSL?
I've never had an issue (so far) dropping in libreSSL whenever openssl is called for.
LibreSSL - the devs have concluded that, so long as TLSv1.2 is used with secure ciphers, it is every bit as secure as TLSv1.3 - but they still include some ciphers that have been more successfully attacked.
The library itself has the kind of compatibility hooks, and zealous porters out there that you'll be surprised what works.
You know all those changes that happened between OpenSSL v1.0 and v1.1? Every project had to work hard to accomodate those changes - compiling that code for older versions still has to work, or companies freak out.
Add LibreSSL into the correct side of the header-files' if-statements. Usually its legacy, but we're recently having to consider different versions of LibreSSL.
When a single if-statement begins to span three lines for readability's sake, you know you're shoving LibreSSL into the seam between OpenSSL versions.
Libp11, the backend for Yubikeys was surprisingly simple to get running on a different SSL backend. Three additional if-statements in one header-file, and one extended out. Code compiles, works beautifully, even past LibreSSL's v2.8.3 that I was running at the time.
BoringSSL - while Im less intimately familiar with Google's offering? I thought they were the first to implement TLSv1.3 - years before anyone else was even considering it.
I have no experience porting anything to it. The only folks I know who do? Are Google Engineers, writing proprietary code. The API is explicitly flagged as unstable/quickly changing on their github mirror.
Google, like always, doesnt care about your needs.
I mostly wanted to question the
> Openssl is known .... for its kitchen sink
and then juxtaposing it with forks of it that retain a lot of its features and compatibility with it.
LibreSSL worked hard to add a few additional ciphers before OpenSSL.
BoringSSL implemented TLSv1.3 years before OpenSSL did.
Is it possible to use RustLs from C? Is a C header available?
Rust works pretty well with C, and you could use cbindgen[0] to generate c headers for rust functions marked as extern and it would work when linked together. However, rustls doesn't seems to be providing any such function. Most of its API is rust-based, using stuff that isn't directly available in C (Option, Vec, etc.). So you would have to write at least some rust code that calls the library, and have your C code calls the rust code that you write.
On the flip side, calling C code in rust is pretty easy - you have the entire libc available, and rust-bindgen[1] generate bindings for you, which in my experience works very well. So, you may also consider writing your program in rust… If that's possible.
[0]: https://github.com/eqrion/cbindgen [1]: https://github.com/rust-lang/rust-bindgen