Large web companies like Google implement their own encryption stack anyway.
On the BSD's I've used, LibreSSL is a standard kernel configuration option. I'll note on FreeBSD, LibreSSL lacks the in-kernel fast path, last I checked.
> Large web companies like Google implement their own encryption stack anyway.
Google uses BoringSSL[1], which is another OpenSSL fork. I believe AWS uses a mix of OpenSSL and Boring SSL (someone can correct me!).
So it's "their own encryption stack," but that stack is at least originally comprised of OpenSSL's code. They've probably done an admirable job of refactoring it, but API and ABI constraints still apply (it's very hard to change the massive body of existing code that assumes OpenSSL's APIs).
Forgive my ignorance, but all of these forks are also still open source? My impression was that patches and improvements were made in closed source, private repositories to the benefit of the companies without paying anything back.
Otherwise, couldn't some openssl contributors just crib fixes from the forks?
As far as I know, all of the major ones are. I don't believe anybody has attempted to make a closed fork of OpenSSL, at least not one that has gained any real traction.
> Otherwise, couldn't some openssl contributors just crib fixes from the forks?
They do! But I assume it gets balanced with their own feature development time, and it becomes harder as the codebases drift. OpenSSL probably hasn't done itself many favors with the recent (3.x) "providers" refactor.
On the BSD's I've used, LibreSSL is a standard kernel configuration option. I'll note on FreeBSD, LibreSSL lacks the in-kernel fast path, last I checked.