Slouching towards a cryptography monoculture

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


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

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.
 
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.
 
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.
 
OK both is of equal importance. Using modern protocols that bypass known vulnerabilities of previous approaches is also important, right?
 
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.
 
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.
 
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.

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.
 
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.
 
If anything, this is just much too late.
Apparently not. I might describe it as "finally," though.

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