# Slouching towards a cryptography monoculture



## Jose (Mar 6, 2021)

I'm saddened and disappointed by the current trend of jettisoning support for Libressl.





						Switching back to OpenSSL
					

The Void Linux team is switching back to OpenSSL on March 5th, 2021 (2021-03-05).




					voidlinux.org
				











						LibreSSL support discontinued – Gentoo Linux
					

News and information from Gentoo Linux




					www.gentoo.org
				








						PEP 644 – Require OpenSSL 1.1.1 or newer | peps.python.org
					

Python Enhancement Proposals (PEPs)




					www.python.org
				




I'm puzzled by the failure to learn from the Heartbleed fiasco, which happened just seven years ago. I'm naturally paranoid, but this is not always a flaw. I'm not the only one who suspects new Openssl "features" are designed to break compatibility with Libressl and return to market dominance. I think PHK's pointed criticism still applies:




_View: https://www.youtube.com/watch?v=fwcl17Q0bpk_


The Openssl Software Foundation is still a for-profit corporation offering commercial support and FIPS compliance. I also find it interesting that the vulnerability comparison section of the Wikipedia page referenced in this Python library has now disappeared. I think it probably looked something like this:





						LibreSSL - Glitchdata
					






					wiki.glitchdata.com
				




Even if you think that my tinfoil hat is too tight and has cut off circulation to my brain, maybe you'll agree that monocultures are inherently fragile:





						Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
					






					www.mail-archive.com


----------



## zirias@ (Mar 6, 2021)

And then, you can just look at that from the pragmatic side. I have submitted quite a few libressl-patches for FreeBSD ports. Some day I was asked by one of the ppl maintaining Qt to please test their branch on github with libressl before they commit it to official ports. Of course I found something that needed to be changed.

Let's face it: LibreSSL promised to be a drop-in replacement for OpenSSL, but it never was in practice. And I'm not even talking about binary compatibility here ... plain API stuff. Combine that with the fact there is no standardized API for a crypto library (so, OpenSSL API became the "de-facto standard" everyone uses in their projects). Now combine that with the fact that OpenSSL also learned lessons from the fiascos happening before.

Maintaining compatibility with LibreSSL is a major PITA. I still use it, but I might drop it as well once I hit a real roadblock. You just can't expect distributors to sacrifice countless hours/days of work, just so all software they package works fine with LibreSSL.


----------



## Beastie7 (Mar 6, 2021)

I imagine it's a lot of work switching to a fork of a library that many applications and service depend on. I doubt it's worth the trouble than just fixing OpenSSL collectively. Honestly, I think there should be a from scratch rewrite with some OpenZFS-style governance. The OpenBSD folks are a rigid bunch I say.


----------



## ct85711 (Mar 6, 2021)

It's not surprising in that distro's are dropping LibreSSL.  As like some of the news said about it, that fork started off fixing what OpenSSL wouldn't even consider fixing to start with.  Didn't help, when OpenSSL decided to do a major API design breaking change and refused to support a transition layer so other projects can catch up.  Even later, LibreSSL just could not keep up on maintaining compatibility with OpenSSL.  Even on Gentoo, LibreSSL ended up being a second class person that you constantly had to fight everything to keep the system semi-stable.


----------



## msplsh (Mar 6, 2021)

Beastie7 said:


> should be a from scratch rewrite


I would imagine something like this using Rust would be of interest.  Lot of careful work to do, however


----------



## Jose (Mar 6, 2021)

msplsh said:


> I would imagine something like this using Rust would be of interest.  Lot of careful work to do, however








						LibreSSL languishes on Linux [LWN.net]
					






					lwn.net
				








						LibreSSL languishes on Linux [LWN.net]
					






					lwn.net


----------



## msplsh (Mar 6, 2021)

Not sure what I'm supposed to take away from this other than that project is not doing "careful work" in the eyes of some people?


----------



## Phishfry (Mar 6, 2021)

HardenedBSD Switching Back to OpenSSL | HardenedBSD
					






					hardenedbsd.org


----------



## Jose (Mar 6, 2021)

msplsh said:


> Not sure what I'm supposed to take away from this other than that project is not doing "careful work" in the eyes of some people?





> The problem, for me, with rust is everything other than the language itself. And in that project you linked to, I'm not sure I'd trust it anymore than something written in modern memory safe C++ (e. g. looking at the places they use "unsafe").
> 
> But the npm style approach that rust projects seem to take wrt. dependencies makes it harder to trust rust projects for me, for example.





> Also, it's not entirely clear to me exactly _how_ much safer this is. rustls uses ring, which is derived from BoringSSL which of course is ultimately OpenSSL plus maintenance work. So at least some of the time the actual code running is (or could be?) literally identical. This is a contrast to some projects that weren't so performance critical and were able to entirely replace C with Rust like-for-like. Is it worth it anyway? Maybe.





> No one in fancy languages camp wants to deal with backward compatibility obviously.


----------



## msplsh (Mar 7, 2021)

At the risk of being rude, replying in quotes is just whataboutism.  I'll just elongate my original post by saying that in the spirit of the thread being concerned about monoculture, a second implementation in a memory-safety-oriented language like Rust (which would have prevented something like heartbleed) would be "of interest" to people (as demonstrated by the mere existence of what you linked:MesaLink) but _of course_ (as contained in the links) implementations would need to be careful, which can mean any sort of thing from dependency curation, build tooling, how closely algorithm implementations are just straight up copied, not using the unsafe hatch, to being obstinate and/or lazy in implementing to a standardized specification.


----------



## Snurg (Mar 7, 2021)

Maybe the 'Heartbeat' incident was the minor problem.
The major problem might have rather been the intervention of the radicals around de Raadt that changed the SSL world.
This was a loss of control accident, a kind of Chernobyl.

Now this undermining strategy is interesting.
So many "donations" of dubious origins pouring into this disguised "nuclear" company, and out of it.
Bribing free software developers, what a disgusting trend  

I guess the trustability of a particular software team can soon be measured by looking at their attitude against libressl.
In cases like HardenedBSD I guess it is not a lack of good will, but of resources.
But with big donation takers like Mozilla Foundation, this might become interesting to look who pushes most for abandoning libressl.


----------



## Deleted member 66267 (Mar 7, 2021)

Excuse me please but I think there is GnuTLS, too? Please correct me if I was wrong.


----------



## unitrunker (Mar 7, 2021)

and BearSSL and others.


----------



## unitrunker (Mar 7, 2021)

I'll say this for LibreSSL: I have fewer problems building it across multiple platforms. Too many dependencies in the tool chain expected by OpenSSL.

Unfortunately the API has a large surface area that will take years to cover.

When LibreSSL was born, they should have named it OpenTLS.


----------



## ShelLuser (Mar 7, 2021)

Well, can't say I'm surprised to see this turn of events. In fact, I predicted this as soon as I learned about LibreSSL. There's nothing here to feed a good conspiracy theory, it all boils down to old fashioned common sense. As Zirias also rightfully mentioned: that "heartbleed comment" goes both ways; why rely on a nobody with all the risks of a possible new security disaster attached to it?  You can say about OpenSSL what you want but it has build up quite a reputation with regards to reliability.

Instead of trying to become an "OpenSSL killer" they would have been better off trying to become "a better crypto engine". I mean... if GNUTLS can (somewhat) pull this off, then why not a new clean engine?

There have been so many projects which tried to become "a better xx project", only to crash and burn. It's one thing to make golden promises, it's another to actually live up to those claims.


----------



## Mjölnir (Mar 7, 2021)

Jose said:


> The Openssl Software Foundation is still a for-profit corporation offering commercial support and FIPS compliance.


There's nothing wrong with that; it's not bad per se.  Programmers have to pay their bills, too.  What's important is that their product is open source, and it is.


Jose said:


> I also find it interesting that the vulnerability comparison section of the Wikipedia page referenced in this Python library has now disappeared. I think it probably looked something like this:
> 
> 
> 
> ...


Yes, IIRC it was like that.  Let's peek into archive.org: Wikipedia:LibreSSL@Feb. 17th, 2018
Of course, behaving like a monopolist & changing public information available in a wiki is what we don't want, and it's good to keep an eye on this.  Especially when it comes to vital building blocks of network security.  This does not mean it was them (or on their demand) who changed that Wikipedia page, though.


Jose said:


> Even if you think that my tinfoil hat is too tight and has cut off circulation to my brain,


Noone thinks that, since your statements are backed up by facts.

On BearSSL, IIUC it's goal is to provide a minimal set of features, to be used in embedded environments?  Whereas LibreSSL aims at beeing a replacement for OpenSSL, which has, due to it's age, some old baggage.  I don't know who decides on all these new security protocols & encryption standards, neither can I judge wether they're reasonable or just maketing blabla.  Eventually it's the programmers/SW-engineers; if they do not use that new stuff, it would be easier to switch to LibreSSL or any other alternative TLS library.  This domain (cryptography & crypt. applied to network security) is evolving rapidly; so maybe it's simply the lack of qualified manpower that LibreSSL suffers from.


----------



## Jose (Mar 7, 2021)

msplsh said:


> At the risk of being rude, replying in quotes is just whataboutism.


No, it's using facts that can be easily verified.


msplsh said:


> I'll just elongate my original post by saying that in the spirit of the thread being concerned about monoculture, a second implementation in a memory-safety-oriented language like Rust (which would have prevented something like heartbleed) would be "of interest" to people (as demonstrated by the mere existence of what you linked:MesaLink) but _of course_ (as contained in the links) implementations would need to be careful, which can mean any sort of thing from dependency curation, build tooling, how closely algorithm implementations are just straight up copied, not using the unsafe hatch, to being obstinate and/or lazy in implementing to a standardized specification.


Right, and Rust makes things like dependency curation difficult. This approach has known problems





						How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript
					

Code pulled from NPM – which everyone was using




					www.theregister.com
				











						Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies
					

The Story of a Novel Supply Chain Attack




					medium.com
				




It's hard to take seriously the security claims of any language that uses this dependency distribution model.


----------



## msplsh (Mar 7, 2021)

Context free facts aren't an argument.  I don't know what you're saying about these things.  Are they good, bad, irrelevant?  Are you making the exact same argument as these people or something more nuanced?

Also, NPM and PIP aren't Crates.io, so I'm not so sure the "approach" is a 1:1 comparison considering how the "exploits" worked.  You're also confusing memory safety for build "security." They're two different issues.


----------



## Phishfry (Mar 8, 2021)

msplsh said:


> Also, NPM and PIP


I am glad you brought this up(outside repository). When I first used PIP I wondered about its security implications.
Here is a tool to install applications that are not visible to pkg. So they could be risky by not being updated by pkg.
Not to mention separate repositories from official FreeBSD.
I will admit when porting a Linux based program it can be useful for chasing dependencies.
Even building/porting applications which do not exist in FreeBSD ports system.

So should PIP be available in pkg form where unknowing python users can really shoot themselves in the foot badly.
When I hear users mention PIP I tend to cringe. You could really dig a shallow grave there.


----------



## ct85711 (Mar 8, 2021)

From what I've seen on Gentoo, there isn't a good solution with pip.  A lot of it is there is tons of packages on pip that you'd have to provide, where as the other side is like you said in that people will use it and shoot themselves in the foot and complain that stuff is broken.  Didn't on Gentoo, their package manager depended on python that pip regularly messed with.


----------



## Jose (Mar 26, 2021)

Fresh new high-severity vulnerabilities in Openssl:





						OpenSSL 1.1.1k Patches Two High-Severity Vulnerabilities | SecurityWeek.Com
					

OpenSSL 1.1.1k has patched two high-severity vulnerabilities: one related to verifying a certificate chain, and one that can lead to a server crash




					www.securityweek.com
				




Lovely spin at the end of TFA


> OpenSSL has come a long way in terms of security since the disclosure of the Heartbleed vulnerability back in 2014.



Why do they feel like they have to market Openssl?

I don't see equivalent problems in Libressl:


			LibreSSL: Releases
		


But hey, let's keep on keepin' on. What could go wrong?


----------



## zirias@ (Mar 26, 2021)

Jose said:


> I don't see equivalent problems in Libressl:
> LibreSSL: Releases


Oh sure, and right now I feel pretty relaxed for using LibreSSL, no need to rush any upgrades 

But the problem persists, there's no standard for a crypto API, so OpenSSL API is the "de-facto standard", and LibreSSL is just following it, which unfortunately has gone wrong many times, requiring to patch software written for OpenSSL…


----------



## Mjölnir (Mar 26, 2021)

Jose, can you judge about the _raison d'être_ (means of existence/right to exist) for all the new encryption standards that force us to rely on _OpenSSL_ & hinder to "simply" switch to an alternate TLS library like _LibreSSL_?  I can not, since I'm a crypto-_noob_.  IIUC many are meant to be an answer to newly found weaknesses & really do enhance security like e.g. PFS (Perfect Forward Security), Multi-Factor-Authentication & DANE.  As long _LibreSSL_ does not support the _most wanted_ of these new standards, we have no choice.


----------



## Jose (Mar 26, 2021)

Please keep in mind as you read what follows that a little knowledge is a dangerous thing, and I only have a little knowledge in this subject.

From what I can tell, the deprecation of Libressl is not being driven by a lack of new features, but rather missing support for new APIs introduced by the Openssl project.

Indeed, the initial revision of the Libressl fork actually had more features than the Openssl release it aimed to replace. Libressl has also introduced a new API, libtls which aims to be "a new TLS library, designed to make it easier to write foolproof applications."

My understanding is that the API plumbing is separated from the actual crypto implementations in both Libre and Open ssl. The crypto code is written and maintained by cryptography experts. The API code is pretty standard systems code.

The Openssl project has introduced many API changes since the Heartbleed fiasco, and has deprecated the 1.0.2 API that was the compatibility basis for the Libressl fork. A cynical person would surmise that these changes and deprecations are at least partially driven by a desire to regain the de-facto monopoly status they had before the fork.


----------



## zirias@ (Mar 26, 2021)

Jose said:


> The Openssl project has introduced many API changes since the Heartbleed fiasco, and has deprecated the 1.0.2 API that was the compatibility basis for the Libressl fork. A cynical person would surmise that these changes and deprecations are at least partially driven by a desire to regain the de-facto monopoly status they had before the fork.


That's not impossible, but unlikely. A "legacy" API often isn't suitable when you move forward, which is the reason for:


Jose said:


> Libressl has also introduced a new API, libtls which aims to be "a new TLS library, designed to make it easier to write foolproof applications."



Now, a new API by LibreSSL won't have any chance when almost every OSS project that needs cryptography uses OpenSSL. So, without some open standard for a crypto API, having more than one implementation always means that one sets the "de facto standard" and all others have to follow. This isn't a good situation.


----------



## msplsh (Mar 26, 2021)

Jose said:


> A cynical person would surmise that these changes and deprecations are at least partially driven by a desire to regain the de-facto monopoly status they had before the fork.


Alternate uncynical take: Heartbleed made a lot of people wake up to the concept that OpenSSL wasn't well maintained, people started working on it in earnest, finding other problems and solving them.  Fresh blood on the project caused a bunch of changes.

The website is completely different since that time.  Documentation no longer has "[STILL INCOMPLETE]" attached to it.  The core team size has expanded by seven members.  Only two of them were there in 2014.


			OpenSSL: The Open Source toolkit for SSL/TLS


----------



## Jose (Mar 26, 2021)

msplsh said:


> Alternate uncynical take: Heartbleed made a lot of people wake up to the concept that OpenSSL wasn't well maintained, people started working on it in earnest, finding other problems and solving them.  Fresh blood on the project caused a bunch of changes.


Again, I'm not versed in the ins and outs of the Openssl APIs, but are drastic and backwards-incompatible API changes really needed for good maintenance? The Libressl project has not felt the need to make these drastic changes and their security record speaks for itself.


----------



## msplsh (Mar 26, 2021)

Jose said:


> are drastic and backwards-incompatible API changes really needed



Maybe...



Jose said:


> The Libressl project has not felt the need to make these drastic changes



 Is this true, though?



Jose said:


> Libressl has also introduced a new API, libtls


----------



## ct85711 (Mar 26, 2021)

Don't make the assumption of the lack reported vulnerabilities meaning it is secure, as it may be just the lack of review to find the vulnerability.


----------



## Jose (Mar 26, 2021)

msplsh said:


>


I meant a lack of vulnerabilities in their implementation of the Openssl 1.0.x API. Also note that the more serious of the two vulnerabilities that were just patched in Openssl was introduced in a recent version:


> Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates...


Version 1.1.1h was released in September of last year. "(W)ell maintained" indeed.


----------



## msplsh (Mar 26, 2021)

I'm confused, are you complaining about bugs or API compatibility?


----------



## Jose (Mar 26, 2021)

ct85711 said:


> Don't make the assumption of the lack reported vulnerabilities meaning it is secure, as it may be just the lack of review to find the vulnerability.


This is just shifting the burden of proof.


----------



## Jose (Mar 26, 2021)

msplsh said:


> I'm confused, are you complaining about bugs or API compatibility?


Maybe I'm misunderstanding what you're saying.

I think you meant that the API changes were necessary because it was difficult or impossible to implement the old API in a secure and correct way. It may be difficult, but it's certainly not impossible because the Libressl project has done it. I certainly don't know how difficult it is to implement.

Libtls is meant to be easier to use, not to be easier to implement. Perhaps it's just as difficult to implement as the original Openssl 1.0 APIs. I also don't know.

Edit: Clarified the end of the second paragraph


----------



## ct85711 (Mar 26, 2021)

I'm not shifting the burden, just saying that the vulnerabilities may be there but either haven't been found and/or reported yet.  There are several cases that some vulnerabilities has been found in code that was written several years ago (I recall some that was in code over 10 years) before it was reported.  Then there are always the cases of some bugs that at the time wasn't considered an issue, later is an issue.  With Libressl, having fewer people using it; reduces the chance someone is going to find a vulnerability/bug.


----------



## Mjölnir (Mar 26, 2021)

Thx 4 reminding me to occasionally rotate my signature.


----------



## Jose (Mar 26, 2021)

ct85711 said:


> I'm not shifting the burden, just saying that the vulnerabilities may be there but either haven't been found and/or reported yet.  There are several cases that some vulnerabilities has been found in code that was written several years ago (I recall some that was in code over 10 years) before it was reported.  Then there are always the cases of some bugs that at the time wasn't considered an issue, later is an issue.  With Libressl, having fewer people using it; reduces the chance someone is going to find a vulnerability/bug.


Fair enough, but I would expect more people to use Libressl because it has fewer discovered vulnerabilities, but instead the opposite is true. Also, widespread usage is not the only way to discover bugs.

In any case, these prove-a-negative arguments are generally considered to be a logical fallacy.


----------



## msplsh (Mar 26, 2021)

In your original post, you link an OpenBSD developer who believes in this conspiracy and then an OpenSSL developer who plainly states he's just incorrect without any receipts (because, why bother re-sending them to people who apparently didn't believe/read them when they were issued).  Here are those receipts:






						OpenSSL - User - [openssl-users] The evolution of the 'master' branch
					

[openssl-users] The evolution of the 'master' branch. As we've already said, we are moving to making most OpenSSL data structures opaque. We deliberately used a non-specific term. :) As of Matt's...



					openssl.6102.n7.nabble.com
				








						OpenSSL 1.1.0 Changes - OpenSSLWiki
					






					wiki.openssl.org
				




LibreSSL forked because they thought OpenSSL wasn't doing a good job maintaining itself.  This would have been an easy job if OpenSSL was actually abandoned, but people stepped up (Evidenced by the LWN link in the Void announcement you linked).  Now the shoe is on the other foot and LibreSSL seems to not be able to/want to keep up.  Maintaining libtls seems like the what the LibreSSL people should pivot to.

If you want to measure things by how many security vulnerabilities they have, that seems kind of subjective since the software has different features.  People have already expressed why they don't want to use LibreSSL and "fewer discovered vulnerabilities" doesn't seem like a compelling counter-argument.


----------



## Mjölnir (Mar 26, 2021)

Jose, the point is that I'll run into non-trivial issues when I set to exchange the SSL/TLS library from _OpenSSL_ to _LibreSSL_.  The latter just doesn't provide all the functionality that OpenSSL offers.  Please help me if I wrong here.  E.g. the Wikipedia entry for DANE lists _OpenSSL_ & _GNU-TLS_, but not _LibreSSL_.  Of course, this site is well known not to be a definit source & this doesn't mean that this is the whole truth.


----------



## Snurg (Mar 26, 2021)

Jose said:


> A cynical person would surmise that these changes and deprecations are at least partially driven by a desire to regain the de-facto monopoly status they had before the fork.


Completely natural for a company that wants to push its competitors out of the market.
"Donations" on all levels, from management to programmers, allow better control of exploits and the like.
From that perspective, OpenSSL company is definitely preferable, worth stuffing with lots of money.


----------



## Jose (Mar 26, 2021)

Mjölnir said:


> Jose, the point is that I'll run into non-trivial issues when I set to exchange the SSL/TLS library from _OpenSSL_ to _LibreSSL_.  The latter just doesn't provide all the functionality that OpenSSL offers.  Please help me if I wrong here.  E.g. the Wikipedia entry for DANE lists _OpenSSL_ & _GNU-TLS_, but not _LibreSSL_.  Of course, this site in well known not to be a definit source & this doesn't mean that this is the whole truth.


I'd never heard of DANE until now. Found lots of pros and cons in a cursory Google search, but they're all old. It does seem like DANE will work in Exim with Libressl:


			[exim-cvs] Fix build with recent LibreSSL,  when including DANE.  Bug 2386


----------



## Jose (Mar 26, 2021)

msplsh said:


> In your original post, you link an OpenBSD developer who believes in this conspiracy and then an OpenSSL developer who plainly states he's just incorrect without any receipts (because, why bother re-sending them to people who apparently didn't believe/read them when they were issued).  Here are those receipts:


Not sure where the receipts are. All I see is that they're going to make most structures "opaque" because reasons. At least one Openssl dev says what they mean by "opaque" is _deliberately vague_.



msplsh said:


> If you want to measure things by how many security vulnerabilities they have, that seems kind of subjective since the software has different features.  People have already expressed why they don't want to use LibreSSL and "fewer discovered vulnerabilities" doesn't seem like a compelling counter-argument.


We'll have to agree to disagree on this. For me number of security vulnerabilities is the number one concern when evaluating the suitability of encryption software. Everything else is secondary.


----------



## Mjölnir (Mar 26, 2021)

The number one concern when evaluating the suitability of encryption software is
fitness to fulfill the purpose.
I.e. when an encryption library lacks to support commonly used standards, it doesn't fit the purpose.


----------



## Jose (Mar 26, 2021)

Mjölnir said:


> The number one concern when evaluating the suitability of encryption software is
> 
> fitness to fulfill the purpose.
> I.e. when an encryption library lacks to support commonly used standards, it doesn't fit the purpose.


To me the purpose of encryption software is, well, to encrypt things. If that encryption is flawed it's useless, and therefore fulfills no purpose.


----------



## Mjölnir (Mar 26, 2021)

OK both is of equal importance.  Using modern protocols that bypass known vulnerabilities of previous approaches is also important, right?


----------



## sidetone (Mar 26, 2021)

OpenSSL was challenged by LibreSSL, and it didn't want to be replaced by it.

As for intention, it's difficult to know whether changing the API was for an improvement or to simply shut out a fundamentally improved LibreSSL from taking it over. It could be a little of both by different people of the OpenSSL project.

I get sick of the argument of, more eyes looking at a project. How many years did 1 feature of a dependency have to compile for 20 hours (by dependencies pulling in more sets of dependencies), when replacing that dependency with a FreeBSD one, allowed it to compile in seconds or minutes? People still don't understand this, when the fact is simply as it's explained. Now it can be audited easier. Something slim and designed well will be easier to audit. Bloated shit will have a lot of hidden problems, and it will remain hidden until it's organized according to function and performance. Not everything is bloated, some things are old, and additions got added on, that needed additional structure.

Python, for instance had to come out with a new version, because it has been added on to for functionality and features. It had to be organized and cleaned around its capabilities and expansions. I see Python as being efficient, despite that removing backwards compatibility was an inconvenience. For a project like Python, either maintaining backwards compatibility or removing backwards compatibility made sense. Hopefully there won't be a need for removing backwards compatibility in the future now, that it is designed for what it now needs. As for OpenSSL, I don't think it's all about making a better project, it's primarily about not fading away. More functionalities were needed, and it got expanded for those functions, then as it expands it gets less organized. It may have been too much to look at to find where to make improvements. Maybe it was too much code to maintain, that there wasn't enough incentive to accomplish a difficult task, then it got challenged.

Still, it's possible that LibreSSL may have lacked structure to replace everything that OpenSSL did. OpenSSL changing its structure for whatever motives there were was is in some way because of LibreSSL.

A problem is that programs that do the same thing often conflict with each other, because they install similar files in the same place. I wanted to use LibreSSL, but couldn't install everything I wanted to, when I tried it. So many programs depended on OpenSSL, too many programs had to be taken care of to do this.


----------



## Jose (Mar 26, 2021)

Mjölnir said:


> OK both is of equal importance.  Using modern protocols that bypass known vulnerabilities of previous approaches is also important, right?


Libressl has supported TLS 1.3 since release 3.2.0 which happened in may of last year.

You're implying that Libressl encourages the use of obsolete and insecure protocols. I'm going to need a source for that claim.


----------



## msplsh (Mar 26, 2021)

Jose said:


> they're going to make most structures "opaque" because reasons



It's right there in the wiki link:

Fields can be changed without breaking binary compatibility
Applications are more robust and can be more assured about correctness
It helps determine which (new) accessors and settors, for example, are needed
(Paraphrased from nabble) Prevent wacky nonstandard unproven hijinks with standard API calls.  Please compile this yourself.
Basically a function-call based API instead of one based on object attributes.  Looks like they had a mix of the two and they just are cleaning up for the purposes of #2 in that list.



Jose said:


> We'll have to agree to disagree on this.


You don't have to agree with me or anybody else.  You just have to recognize that everybody who is dropping LibreSSL doesn't agree with you.


----------



## zirias@ (Mar 26, 2021)

msplsh said:


> Basically a function-call based API instead of one based on object attributes. Looks like they had a mix of the two and they just are cleaning up for the purposes of #2 in that list.


If anything, this is just much too late. Exposing data directly in your API is bad style, prone to (usage) errors and of course makes the API very unstable, cause any substantial change will also be a breaking change of the API. Might very well have been one of the reasons LibreSSL came up with an alternative API.


----------



## Mjölnir (Mar 26, 2021)

Jose said:


> You're implying that Libressl encourages the use of obsolete and insecure protocols. I'm going to need a source for that claim.


Exactly!  `#me 2`!  Please do show me where I wrote THAT!


----------



## msplsh (Mar 26, 2021)

Zirias said:


> If anything, this is just much too late.


Apparently not.  I might describe it as "finally," though.



Zirias said:


> Exposing data directly in your API is bad style, prone to (usage) errors and of course makes the API very unstable, cause any substantial change will also be a breaking change of the API. Might very well have been one of the reasons LibreSSL came up with an alternative API.


Given the choice, people seem to be ok with making minor getter/setter changes to their existing code than adopting a new API.


----------



## Jose (Mar 27, 2021)

Mjölnir said:


> Exactly!  `#me 2`!  Please do show me where I wrote THAT!


We're talking about Libressl, right?


Mjölnir said:


> Using modern protocols that bypass known vulnerabilities of previous approaches is also important, right?


If you're not referring to Libressl, then what is it that is preventing the adoption of the modern protocols?


----------



## msplsh (Mar 27, 2021)

He's talking about DANE support in the abstract.


----------



## Jose (Mar 27, 2021)

msplsh said:


> It's right there in the wiki link:
> 
> Fields can be changed without breaking binary compatibility


Not a security improvement.


msplsh said:


> Applications are more robust and can be more assured about correctness


Does not guarantee robustness or correctness in the library itself. Can maybe make it easier to write correct and robust applications that link with the library.


msplsh said:


> It helps determine which (new) accessors and settors, for example, are needed


Not a security improvement.


msplsh said:


> (Paraphrased from nabble) Prevent wacky nonstandard unproven hijinks with standard API calls.  Please compile this yourself.


Not sure what this means at all. A link to the "hikjinks" in Nabble would've been nice.


msplsh said:


> Basically a function-call based API instead of one based on object attributes.  Looks like they had a mix of the two and they just are cleaning up for the purposes of #2 in that list.


By all means change the curtains to fix the leaky windows. Fluffy interfaces have downsides too. One of the reasons removing the heartbleed "functionality" was so easy is that almost no one used it. It was a misfeature in search of a use case.


----------



## msplsh (Mar 27, 2021)

Uh, it's called "code cleanup" or "refactoring", not "security improvements."  I don't know anything about you, but for myself, as a programmer, doing these sorts of passes over an "API", especially one that just kind of "evolved" instead of being designed, is kind of normal.  I don't know why you're seemingly demanding that the changes be strictly related to security improvements.  Making getters and setters go through function calls make mocking easier so you can build tests against it and do things like put mutexes in to help with threading.  What I'm saying is that this is all _normal_.  Not a conspiracy.

I linked to the Nabble thing.  Did you not read it?  The complaints where that people couldn't hijack standard routines with their own custom experiments and have other apps link to their stuff unwittingly versus just recompiling.  Not a very compelling argument when most of what you'd be linking is open source too.

Complaining that a code cleanup pass is "changing curtains" seems like just being combative.  Have you heard of static analysis?  This sort of change enables those kinds of auditing tools to work.

Heartbeat functionality is part of the DTLS RFC.  OpenSSL didn't invent the "misfeature" out of whole cloth.

What do you even want here?  Start a good old fashioned flamewar similar to Gnome vs KDE?  LibreSSL is complaining they don't have the manpower to "keep up" with basic changes like this, which seems like there is literally not enough available crypto programmers to support two codebases.  Why not just fork 1.1 again after OpenSSL did all the work and re-rip things out, since that's all they seem to be caring about.


----------



## Jose (Mar 27, 2021)

msplsh said:


> Uh, it's called "code cleanup" or "refactoring", not "security improvements."  I don't know anything about you, but for myself, as a programmer, doing these sorts of passes over an "API", especially one that just kind of "evolved" instead of being designed, is kind of normal.  I don't know why you're seemingly demanding that the changes be strictly related to security improvements.  Making getters and setters go through function calls make mocking easier so you can build tests against it and do things like put mutexes in to help with threading.  What I'm saying is that this is all _normal_.  Not a conspiracy.


I agree that these are desirable, but I thought the reason these backwards-incompatible improvements were adopted was because they *had to be* for security reasons. I see no security justifications for them.

Yes, cleanup is important, but so is backwards compatibility, and especially so in a library that is so widely used. Why inflict the pain on your users for nice-to-have improvements? Wouldn't it have been more reasonable to introduce new APIs and leave the backwards-compatible ones alone in maintenance mode?



msplsh said:


> I linked to the Nabble thing.  Did you not read it?  The complaints where that people couldn't hijack standard routines with their own custom experiments and have other apps link to their stuff unwittingly versus just recompiling.  Not a very compelling argument when most of what you'd be linking is open source too.


What I saw was actual cryptologists complaining that testing the crypto parts was becoming more difficult. This is not a compelling argument in favor of the API changes.


msplsh said:


> Complaining that a code cleanup pass is "changing curtains" seems like just being combative.  Have you heard of static analysis?  This sort of change enables those kinds of auditing tools to work.


Please explain how these changes are needed for static analysis.


msplsh said:


> Heartbeat functionality is part of the DTLS RFC.  OpenSSL didn't invent the "misfeature" out of whole cloth.
> 
> What do you even want here?  Start a good old fashioned flamewar similar to Gnome vs KDE?  LibreSSL is complaining they don't have the manpower to "keep up" with basic changes like this, which seems like there is literally not enough available crypto programmers to support two codebases.  Why not just fork 1.1 again after OpenSSL did all the work and re-rip things out, since that's all they seem to be caring about.


I've ignored any sort of meta-arguments about my motives or anyone else's. Those are just not productive. I will continue to ignore them with this one exception.


----------



## msplsh (Mar 27, 2021)

Jose said:


> I thought the reason these backwards-incompatible improvements were adopted was because they *had to be* for security reasons.


Ok, but that's not the case, so why make a fuss about it not exclusively being that way?



Jose said:


> Why inflict the pain on your users for nice-to-have improvements?


Security benefits of static analysis?  Easier to add new features? Nice to have means easier to audit?  It's their codebase?  They went out of their way to _find_ the users this affected and created new functions for their purposes.  Doesn't seem very malicious to me.



Jose said:


> cryptologists complaining that testing the crypto parts was becoming more difficult


I saw "making it much harder to use the library with experimental or non-standard algorithms and methods" which is not the point of most OpenSSL deployments.  Also, if they want to noodle around with it, they can just compile it themselves.  It's not like it's "hidden" in the source, just the binary API.



Jose said:


> Please explain how these changes are needed for static analysis.


Are you a programmer?  If you aren't, then I'm not sure why you're arguing for them.  They're moving things like manually setting structure data behind function calls to set the structure data.  This lowers the variability of entry points for these things changing for security analysis, can provide validation against other variables at assignment time, prevent invalid initialization, etc.


----------



## Jose (Oct 11, 2022)

Just found an interesting article today:




__





						Loading…
					





					www.researchgate.net


----------



## PMc (Oct 11, 2022)

Jose said:


> Just found an interesting article today:
> 
> 
> 
> ...


I read the abstract and conclusion, and couldn't find any relation to the headline.


----------



## msplsh (Oct 12, 2022)

PMc said:


> I read the abstract and conclusion, and couldn't find any relation to the headline


Writing cryptographic software is hard and it's unlikely that "you" are smart enough to do it alone.


----------



## smithi (Oct 12, 2022)

I found phk@'s entertaining and profound presentation that Jose posted way back at #1 pretty well nailed it for me.

We can ignore the politics of encryption and surveillance, but politics won't ignore us.

Resume Normal Transmission ...


----------

