
OpenSSL 3 Strategic Architecture - jbaviat
https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html
======
zdw
The OpenSSL strategy seems to be to try to leapfrog LibreSSL in terms of
version numbers (which already has released a 2.x branch, hence their 3.x
versioning), and revise their API, but still have considerable complexity.

The LibreSSL approach was to write a new library and API, libtls, which does
away with the substantial configuration complexity in applications:
[https://man.openbsd.org/tls_init.3](https://man.openbsd.org/tls_init.3)

I'd argue that LibreSSL's is the better approach.

~~~
kev009
It is supremely unlikely Akamai (via Rich Salz who is leading and has led a
lot of post heartbleed fixup) take libressl seriously at all nor do any other
large contributing company. People in the FreeBSD community knew libressl
would be a flash in the pan given the personalities involved and FreeBSD has
legitimate large scale commercial usage.

~~~
gonzo
OpenVPN also disclaims any interoperability with LibreSSL.

"Please note that LibreSSL is not a supported crypto backend. We accept
patches and we do test on OpenBSD 6.0 which comes with LibreSSL, but if newer
versions of LIbreSSL break API compatibility we do not take responsibility to
fix that."

------
tptacek
_The Core will implement a property based look-up feature for finding
algorithms, e.g. it might allow you find an algorithm where "fips=true", or
"keysize=128, constant_time=true"._

Why? What designer builds a system this way, without knowing precisely what
algorithm they're using?

~~~
tyingq
The fips example seems like a good one. _" Don't care how, tick this box so
I'm compliant with my government contract"_.

Not arguing it's a good idea, just that it might be wanted.

~~~
brians
Wanted the same way HIGH:MEDIUM:LOW was wanted, with a new recipe for late
binding of noncomposable abstractions. Same outcome expected.

------
tatersolid
Yikes. Backwards compatibility is tough.

Strange that with the bump to 3.0 they didn’t at least announce the removal
legacy primitives and TLS versions. Are they going to support DES and RC4
forever?

~~~
userbinator
_Are they going to support DES and RC4 forever?_

It might not be the exact use-case for OpenSSL but there's plenty of existing
content or protocols using those algorithms, which no one is going to bother
changing ("encrypted" PDFs come to mind).

In any case not having RC4 isn't such a big deal; it's a tiny algorithm you
could literally memorise and write into where it's needed (which I suspect is
why it became so popular.) DES is a bit trickier though.

~~~
tatersolid
Let PDF readers find their own DES library. Or at lest make its non-default
part of the build.

But even having it there as optional is risky and adds to an already huge
maintenance burden. You know the distro packagers will enable every feature
just like they did with DTLS support (which is what made Heartbleed
pervasive).

Packagers don’t want to deal with complaints and support tickets because their
OpenSSL build doesn’t do 3DES. So they turn on all the things.

------
snvzz
Still prefer libressl. A shame that openssl's history of failing at security
is rewarded with donations and use, rather than shunned.

~~~
IloveHN84
But libressl breaks ABI compatibility (see that BSD is taking a step
backward).

OpenSSL is affected by what we can call "fame". It's the mostly wide used
security library in the whole internet and it's the favourite target for
hackers. For comparison, it's the same that happens to OS: windows and android
are the preferred target platforms because of the large user base they have.

~~~
myst
> But libressl breaks ABI compatibility

Who cares? Compatibility with insecurity is not a goal.

~~~
acdha
Are you volunteering to patch every program which uses OpenSSL? If not, you
have the answer: it’s been widespread for decades and so many things use it
that compatibility is a big concern. Think about a distribution like Debian
with thousands of packages, some of which update frequently and others which
haven’t been updated in years. If it’s compatible, you can ship one shared
library update but if it’s not you’re either not upgrading or maintaining a
ton of patches.

~~~
icebraining
Debian is a bad example; they compile everything from scratch, they don't need
ABI compatibility.

------
brians
Neat. I look forward to better FIPS handling and the deprecation story.

And to vulnerabilities from the loadable module support. Getting the property
based binding right looks tough!

