LibreSSL languishes on Linux
OpenSSL provides the low-level plumbing for a number of important cryptographic functions; it provides TLS and SSL implementations and a number of utilities for functions like key generation and signing. Most programs that need to communicate securely over the network end up linking to OpenSSL for that functionality. OpenSSL has always had a bit of a strange position in the Linux world due to its special license, which contains an advertising requirement that is deemed to be incompatible with the GNU General Public License. To get around this problem, many GPL-licensed programs include a special exception allowing linking to OpenSSL.
Our systems are built upon a frightening number of crucial components that everybody uses, but which nobody maintains. In 2014, the disclosure of the Heartbleed vulnerability made it clear that OpenSSL was one of those components; it had languished with minimal development effort for years. As a result, the OpenSSL code base had filled up with unmaintained cruft — and catastrophic vulnerabilities. Heartbleed was seen as being bad enough that Something Had To Be Done to improve that situation.
One of the things that was done was the establishment of the Core Infrastructure Initiative (CII) by the Linux Foundation; its goal was to direct resources to crucial components that were insufficiently supported. The CII has faded somewhat over the years, but it did succeed in bringing developers to projects like OpenSSL and patching over many of our worst problems with unsupported infrastructure.
The OpenBSD project, as is its wont, took its own approach; the result was the LibreSSL fork. Within a couple weeks of the Heartbleed announcement, the LibreSSL developers claimed to have removed about half of the code forked from OpenSSL. The OpenBSD distribution switched over to the new library, and the project seemed to be off to a running start. Over nearly six years, LibreSSL has remained a viable project, producing regular releases as it goes. Since the 2.9.0 release at the end of 2018, the project has merged 1,554 patches from 36 developers, showing that it is definitely alive and getting work done.
The OpenSSL project, though, has merged over 5,000 patches during approximately the same time period; that work came from 276 developers. Just as importantly, much of that work is supported by organizations that depend on OpenSSL; large contributors include Oracle, Siemens, Akamai, Red Hat, IBM, VMware, Intel, and Arm — along with the OpenSSL Software Foundation itself. This level of support has enabled the OpenSSL project to address many of its longstanding problems; by 2016, the project was on a much more stable footing. Security problems still exist, of course — this is software we are talking about, after all — but they are dealt with in a coordinated way and people don't worry about OpenSSL as they once did.
One result of all this work is that Linux distributions have, in general, not shifted away from OpenSSL. Two distributions that did attempt to provide LibreSSL support were Alpine Linux and Gentoo. Alpine Linux supported LibreSSL as its primary TLS library for a while, but switched back to OpenSSL with the 3.9.0 release in January 2019. Gentoo never tried to switch over completely, but it supports LibreSSL as an alternative.
That support will end in February, though. Gentoo developer Michał Górny first suggested this change at the end of December, saying that LibreSSL offers no benefit over OpenSSL at this point while imposing a lot of costs. In particular, he complained about the large number of packages that require patches to work with LibreSSL and the constant stream of regressions that the project must deal with. Various other developers were quick to support this change. Hanno Böck, who claimed to be the first to have built Gentoo with LibreSSL, said:
Anthony Basile, who is the current lead for LibreSSL on Gentoo, agreed,
saying that LibreSSL is "more of a hassle than it's worth
".
The primary opposition came from Peter Stuge, who asserted
that "Gentoo is about choice and this particular component is one of
the most important in a system
". He also made the
point that monocultures are not healthy in any part of the system, so
it is good to support alternatives like LibreSSL. Even Stuge seemed to
agree, though, that supporting LibreSSL at its current level was not
sustainable and didn't seem to make sense. But he thought LibreSSL should
remain part of the distribution for those who want to go to the trouble to
try to use it.
Even that may be a bit challenging, since it is not possible to install both OpenSSL and LibreSSL on the same system. But that is the approach that is being taken; LibreSSL will remain in the Gentoo repository — for now — but it will be "masked" to prevent its installation by users who have not taken extra action to enable it. As noted in the announcement, the Gentoo project will also stop carrying patches to make other packages work with LibreSSL:
It has now become difficult indeed to find a Linux distribution that is still trying to support LibreSSL over OpenSSL.
One might try to argue that the LibreSSL fork has failed, but that is clearly not the case; it is under active development and is used by at least a couple BSD variants. One could argue, though, that this fork was done too soon. This project was created only a couple of weeks after the disclosure of Heartbleed, which seems rather too early to conclude that the problems with OpenSSL itself could not be addressed without a fork. OpenSSL turned out not to be as unfixable as it seemed, and OpenBSD is saddled with the cost of carrying its own fork rather than benefiting from the rejuvenated OpenSSL effort.
Perhaps, someday, OpenSSL will run aground again and the world will be glad
that there is a LibreSSL project out there to fall back to. Alternatives
are good, and the ability to create those alternatives is one of the great
strengths of free software. But alternatives can also be expensive to
support, and it would appear that the Linux community has decided that this
particular alternative is not worth the price.
| Index entries for this article | |
|---|---|
| Security | OpenSSL |
| Security | Secure Sockets Layer (SSL) |
Posted Jan 4, 2021 22:17 UTC (Mon)
by timrichardson (subscriber, #72836)
[Link] (13 responses)
Posted Jan 4, 2021 23:17 UTC (Mon)
by josh (subscriber, #17465)
[Link] (12 responses)
Posted Jan 5, 2021 0:12 UTC (Tue)
by Sesse (subscriber, #53779)
[Link] (11 responses)
Posted Jan 5, 2021 3:12 UTC (Tue)
by josh (subscriber, #17465)
[Link] (3 responses)
Posted Jan 5, 2021 6:31 UTC (Tue)
by krijgdenergstenkanker (guest, #125984)
[Link] (2 responses)
Posted Jan 5, 2021 6:47 UTC (Tue)
by dvdeug (guest, #10998)
[Link] (1 responses)
Posted Jan 5, 2021 23:35 UTC (Tue)
by pm215 (subscriber, #98099)
[Link]
Posted Jan 5, 2021 4:18 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (2 responses)
https://lists.debian.org/debian-devel/2020/10/msg00165.html
Posted Jan 5, 2021 7:41 UTC (Tue)
by edomaur (subscriber, #14520)
[Link] (1 responses)
Posted Jan 5, 2021 7:44 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Jan 5, 2021 7:10 UTC (Tue)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Jan 5, 2021 9:49 UTC (Tue)
by joib (subscriber, #8541)
[Link]
Posted Jan 5, 2021 8:58 UTC (Tue)
by joib (subscriber, #8541)
[Link]
Posted Jan 5, 2021 15:15 UTC (Tue)
by paravoid (subscriber, #32869)
[Link]
Posted Jan 4, 2021 22:38 UTC (Mon)
by djc (subscriber, #56880)
[Link] (10 responses)
Posted Jan 5, 2021 2:49 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
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.
Posted Jan 5, 2021 14:02 UTC (Tue)
by wqweto (guest, #143975)
[Link] (2 responses)
No one in fancy languages camp wants to deal with backward compatibility obviously.
cheers,
Posted Jan 5, 2021 14:49 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
So AES-CBC is something that you'd want to use with >10 year old code that hasn't been upgraded since then.
Posted Jan 5, 2021 20:17 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link]
Of course the IETF does not have an enforcement arm, if you don't want to implement arguably unsafe choices like TLS_RSA_WITH_AES_128_CBC_SHA then nobody will actually force you to do so. A TLS 1.2 client that only does ECDHE will work on a lot of the web today, and avoids any concerns with how unsafe RSA kex is, but it would not be compliant with the standard and isn't compatible enough that you could say, ship it in a mass market web browser today, likewise for AEAD suites.
Posted Jan 6, 2021 21:10 UTC (Wed)
by njs (subscriber, #40338)
[Link]
Posted Jan 15, 2021 15:41 UTC (Fri)
by sandsmark (guest, #62172)
[Link] (4 responses)
But the npm style approach that rust projects seem to take wrt. dependencies makes it harder to trust rust projects for me, for example.
Posted Jan 15, 2021 15:48 UTC (Fri)
by sandsmark (guest, #62172)
[Link] (3 responses)
Posted Jan 18, 2021 8:23 UTC (Mon)
by laarmen (subscriber, #63948)
[Link] (2 responses)
Posted Feb 2, 2021 11:08 UTC (Tue)
by sandsmark (guest, #62172)
[Link] (1 responses)
The rest of the code doesn't seem particularly defensively written, compared to something like Botan (which nicely illustrates how using C++ and not C impacts security, all of their issues would have been just as or more likely to happen with mesalink: https://botan.randombit.net/security.html).
And looking at their code, mesalink seems more prone to raw memory issues than Botan: https://github.com/mesalock-linux/mesalink/search?q=unsafe
Posted Feb 2, 2021 18:17 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jan 4, 2021 22:43 UTC (Mon)
by chutzpah (subscriber, #39595)
[Link]
Void Linux still uses LibreSSL, but it looks like they are debating at switching back to OpenSSL: https://github.com/void-linux/void-packages/issues/20935
Posted Jan 4, 2021 23:21 UTC (Mon)
by tiran (guest, #94212)
[Link]
Posted Jan 5, 2021 5:18 UTC (Tue)
by flussence (guest, #85566)
[Link] (17 responses)
Part of the problem has always been that SSL itself is a byzantine solution that requires an entire industry to keep afloat one facet of security that's automatic and frictionless in most protocols that aren't built on 1960s tech. It took multiple scandals and panics just to get a usable free CA to appear, and it's taken until 2020 just for browsers to stop screaming at the user that a self-signed cert is less secure than plain HTTP. Those aren't symptoms of a functional system.
Posted Jan 5, 2021 9:17 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link] (14 responses)
Do you have an example of "most protocols that aren't built on 1960s tech" which can deliver the three things TLS offers: Authentication, Confidentiality, Integrity - for the public Internet and in a way that's "automatic and frictionless" ?
RFC 8446 seems to me to be a relatively small document, you certainly couldn't implement it in a weekend, but aside from the very strange spelling of the protocol (e.g. HelloRetryRequest is spelled as a ServerHello) which we can blame firmly on middeboxes, it's extremely intuitive and I was very pleased with how elegant it is.
Posted Jan 5, 2021 12:27 UTC (Tue)
by Lennie (subscriber, #49641)
[Link] (1 responses)
Posted Jan 5, 2021 20:35 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link]
The nice thing is that (within their assumptions†) the correctness proofs don't care about extensions. If you use certificate compression (forthcoming TLS 1.3 extension) or flags (likewise) or even Encrypted Client Hello (far more radical, but ultimately expressed as an extension) you keep all the behaviours that were proved, because the proof doesn't care.
† And there's a crack. For example the only known TLS 1.3 attack "Selfie" depends on an unstated assumption of the proof. The proof assumes PSKs are singular, if Alice and Bob each run both a TLS client and a server secured just by PSK, they actually need _two_ PSKs, the Alice->Bob key and the Bob->Alice key. But this assumption isn't spelled out. Lacking such explicit warning you might assume one Alice+Bob key will get the job done, then Mallory redirects Alice's call to Bob back to Alice, Alice's client assumes she's talking to Bob and mistakes her own answers for Bob's. Does that blow up your security? Alas RFC 8446 as written does not warn you that this would happen and what countermeasures you should use to avoid it.
Posted Jan 5, 2021 13:51 UTC (Tue)
by shaded-enmity (guest, #119983)
[Link] (1 responses)
I don't understand the logic behind this argument. The boom of the internet wasn't about things being secure, but about things being connected and accessible. You can't have your cake and eat it too.
Posted Jan 5, 2021 14:40 UTC (Tue)
by smoogen (subscriber, #97)
[Link]
Posted Jan 5, 2021 14:48 UTC (Tue)
by flussence (guest, #85566)
[Link] (5 responses)
Posted Jan 5, 2021 20:55 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
Secondly, RFC 8446 is designed to work fine without certificates. You get a complete working system, including forward secrecy. However in this model you'll need to agree Pre Shared Keys with every single server you want to talk to (and they should agree separate keys with each of their clients). This might be nice for a system that connects speakers in each room of your home over WiFi to a central music playing device for example, but it's not viable for visiting arbitrary web sites.
The need for a PKI (and thus Certificates) happens when you'd like (as we do) to securely authenticate any system connected to the Internet. And this isn't out of some weird fetish for as you say 1960s technology, we simply do not know any alternatives that actually work. The usual claims are either that TOFU is "good enough" (good enough that you'll get exploited and never know it, perhaps) or that the Web of Trust works at scale (it does not).
Posted Jan 5, 2021 22:38 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Instead we should have pushed DNSSEC-based security, this way you only need to trust you domain name registrar instead of ALL three hundred or so certificate issuers in all kinds of jurisdictions.
Posted Jan 6, 2021 2:20 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
The other problem is that the system you are describing already exists. It's called DANE, and the basic difficulty with it is that a surprisingly large number of users are (or were) using an amazingly bad DNS resolver that can't even look up a simple TXT record, let alone pull down an entire X.509 certificate.[1] Also, there are crypto issues (which I don't pretend to understand).
Posted Jan 6, 2021 2:28 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> It's called DANE
Posted Jan 6, 2021 8:22 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link]
For Chromium the relevant code is published: https://source.chromium.org/chromium/chromium/src/+/maste... look at lines around 950 or so
There are four epochs we care about:
1. Ancient history, before there were any rules at all, Chromium arbitrarily assumes certificates must not have had lifetimes exceeding ten years. Did any certificates actually do that? Maybe, but they've never worked in Chrome, so we can assume they're not used. This epoch ended in 2019, and so is now irrelevant
2. The original Baseline Requirements began in July 2012 and allow 60 months (which is to say, five years) for grandfathered scenarios. However in April 2015 this rule changed, so the last such certificate expired last year, in April 2020.
3. The "modern" Baseline Requirements from April 2015 allow 39 months in all cases. This regime ended by consent in March 2018. So the last such certificate expires 1188 days after that at the end of May 2021, almost five months from now.
4. The last such consensual BR amendment in March 2018 allows 825 days. This ended de facto in September 2020. So the last such certificate expires 825 days later, in December 2022. _However_ the CT enforcement rules start May 2018. So a "backdated" certificate issued under this regime has to be prior to May 2018, which means it expired during or before August 2020, last year.
Thus, as you can see, the only backdating option that could mechanically work is a certificate which claims it was issued in late 2017 or early 2018 and expires before end of May 2021.
It is extremely unlikely that such certificates have been created after the CT deadline or will be made in the next few months. If detected they would likely result in the issuing CA being distrusted, yet their practical value to a subscriber is minimal compared to just getting a CT logged certificate.
But if you're concerned anyway and can't wait until June this year simply modify Chromium source to always require SCTs. In practice there likely won't be any sites you use that are still relying on this very narrow exclusion window to function, by February 2018 most vendors were giving unsophisticated subscribers certificates with SCTs baked in already and 1188 days is the very maximum allowable, most certificates will have had far shorter lifespans.
Posted Jan 7, 2021 10:45 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (3 responses)
As someone who has issues with Tim due to his stance on EME and other user-hostile additions to recent web specs, I find this a bit harsh. HTTP is clearly modelled on similar protocols of the era, like FTP, SMTP and NNTP, all of which were similarly insecure. Tim was copying standard network protocol practices of the time, and adding encryption to early HTTP specs would have been a mammoth task for one person's personal project. Especially if they probably didn't have extensive cryptographic experience, and for a protocol that no-one at the time could have predicted would be as important and ubiquitous as it eventually turned out to be.
Posted Jan 7, 2021 11:49 UTC (Thu)
by geert (subscriber, #98403)
[Link] (2 responses)
After one-too-many pranks, the latter was quickly replaced by custom scripts calling xauth and copying over magic cookies to remote systems.
Posted Jan 7, 2021 13:15 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
Don't forget that at the time, there were some very real legal issues with respect to strong encryption.
Posted Jan 7, 2021 13:20 UTC (Thu)
by geert (subscriber, #98403)
[Link]
Posted Jan 6, 2021 1:02 UTC (Wed)
by josh (subscriber, #17465)
[Link] (1 responses)
Insofar as they're finally marking plain HTTP as being just as insecure. Encryption is not security, if you don't know who you're talking to.
Posted Jan 14, 2021 15:39 UTC (Thu)
by brunowolff (guest, #71160)
[Link]
Posted Jan 5, 2021 6:17 UTC (Tue)
by dannyobrien (subscriber, #25583)
[Link] (8 responses)
Posted Jan 5, 2021 8:04 UTC (Tue)
by flussence (guest, #85566)
[Link] (2 responses)
Posted Jan 5, 2021 9:52 UTC (Tue)
by ale2018 (guest, #128727)
[Link]
Overall, GnuTLS API seem to me to be more consistent, which presumably allows the library to grow with less constraints.
Posted Jan 6, 2021 12:54 UTC (Wed)
by ametlwn (subscriber, #10544)
[Link]
The OpenSSL compatibility layer covers only a very small subset of the API. And it has stayed unchanged for a very long time, afaict it is in we-will-drop-it-if-it-breaks-status.
Posted Jan 5, 2021 8:06 UTC (Tue)
by ncm (guest, #165)
[Link] (1 responses)
Also curious about the condition of libnss.
And, what is this about openssl 2 and 3? All I have seen lately are 1.1.?.
Posted Jan 5, 2021 9:19 UTC (Tue)
by joib (subscriber, #8541)
[Link]
1.1.1 is the latest release series. The next release is 3.0, which is still in development. For some reason they skipped 2.x.
Posted Jan 5, 2021 8:51 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link]
Posted Jan 5, 2021 13:23 UTC (Tue)
by cortana (subscriber, #24596)
[Link] (1 responses)
In the most recent Cryptographic Right Answers, one (group of) cryptographers simply has this to say:
Use AWS ALB/ELB or OpenSSL, with LetsEncrypt.
If you can pay AWS not to care about this problem, we recommend you do that.
Otherwise, there was a dark period between 2010 and 2016 where OpenSSL might not have been the right answer, but that time has passed. OpenSSL has gotten better, and, more importantly, OpenSSL is on-the-ball with vulnerability disclosure and response.
Using anything besides OpenSSL will drastically complicate your system for little, no, or even negative security benefit. So just keep it simple.
Speaking of simple: LetsEncrypt is free and automated. Set up a cron job to re-fetch certificates regularly, and test it.
Avoid: offbeat TLS libraries like PolarSSL, GnuTLS, and MatrixSSL.
Posted Jan 5, 2021 15:43 UTC (Tue)
by ber (subscriber, #2142)
[Link]
Posted Jan 5, 2021 10:02 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (6 responses)
Can't all these projects share some common test suite? It's not like they require mocking up hardware or complex dependencies, do they?
Posted Jan 5, 2021 13:28 UTC (Tue)
by idra (guest, #36289)
[Link] (4 responses)
Posted Jan 5, 2021 18:39 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (3 responses)
Could you summarize why a test suite portable across all these implementations is not easy? I naively believe they implement the same API.
Posted Jan 6, 2021 10:24 UTC (Wed)
by hkario (subscriber, #94864)
[Link] (2 responses)
it works both as a test suite and a fuzzer, with existing test cases placing far more emphasis on the test suite and compliance parts than on fuzzing part. In other words, it's can be a TLS fuzzer, some test scenarios behave like a fuzzer, but it's not only a TLS fuzzer.
Full disclosure: I'm the primary developer of tlsfuzzer
> Could you summarize why a test suite portable across all these implementations is not easy? I naively believe they implement the same API.
they don't
while few libraries implement OpenSSL API, it's not complete reimplementation, usually limited only to a subset of calls necessary to perform TLS connections, nothing more. Also it's only some of the libraries. For example NSS (library used by Firefox) doesn't do it, BoringSSL is also API incompatible now with OpenSSL.
so, the libraries in question implement the same protocol, and need to interoperate with each-other, but that doesn't mean they implement the same API for applications to use them
Posted Jan 6, 2021 23:20 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (1 responses)
My assumption that it was just a fuzzer was based on the README there; you may want to rephrase it a bit. I missed the title in the top-right corner and scroll straight down to the README which starts like this:
> Fuzzer and test suite for TLS (SSLv2, SSLv3, v1.0, v1.1, v1.2, v1.3) implementations.
... which I misread as "Fuzzer and [fuzzing] test suite for...".
The name "tlsfuzzer" does obviously not help either.
> they don't
Thanks for all the info!
Posted Jan 7, 2021 15:12 UTC (Thu)
by hkario (subscriber, #94864)
[Link]
I did, please check if it's clear now.
> The name "tlsfuzzer" does obviously not help either.
there are 2 things that are hard in computer science: cache invalidation, naming things and off by one errors ;)
on more serious note: you can use it as a simple, dumb, fuzzer, but all included scripts (with exception of like 1 or 2) don't; they expect very well defined behaviour from the server. Recently we're extended test coverage to testing even the timing of server responses.
also, it's more about the future scope of the project; I want to make it actually mutate the existing scripts to create new test scenarios randomly
so it's a more like "TLS property based tester" but that doesn't exactly roll off the tongue
Posted Jan 6, 2021 13:04 UTC (Wed)
by ametlwn (subscriber, #10544)
[Link]
Posted Jan 5, 2021 11:56 UTC (Tue)
by bangert (subscriber, #28342)
[Link] (1 responses)
Does anyone know how the number of lines of code evolved in the original OpenSSL. Did they also remove a lot?
Posted Jan 5, 2021 20:24 UTC (Tue)
by HenrikH (subscriber, #31152)
[Link]
Posted Jan 5, 2021 15:08 UTC (Tue)
by joey (guest, #328)
[Link] (1 responses)
Posted Jan 6, 2021 2:43 UTC (Wed)
by Flameeyes (guest, #51238)
[Link]
(Although I have explicitly stopped looking into the topic since then.)
Posted Jan 7, 2021 2:22 UTC (Thu)
by mm7323 (subscriber, #87386)
[Link]
Since then I never looked back, but this article makes me think the time might be right.
Posted Feb 1, 2021 17:43 UTC (Mon)
by netghost (guest, #54048)
[Link] (5 responses)
Everybody knows to create a separate fork will cause hassle, nobody needs to be reminded about this well established fact. And OpenSSL obviously attracts more attention from bigger companies mentioned in the article, this was obviously already the case before OpenSSL was publicly criticized for its security issues.
So to use that OpenSSL has a larger development community and more patches committed to show that "LibreSSL languishes" on Linux is merely repeating the opinion "we have more people so we win the votingwar against LibreSSL". LibreSSL may exactly choose not to become "popular" in such domain just for the sake of a better security.
For a reference:
It is indeed true many mainline Linux distributions does not officially support libreSSL on Linux for the sake of convenience instead of security (which is always true). But it languishes on Linux? Security focused developer will still evaluate, choose to link a better library themselves, whether he is on Ubuntu, Redhat or Android. It seems that LWN no longer thinks Linux users who choose to compile and link libraries on their own are part of "Linux communities".
Posted Feb 4, 2021 1:20 UTC (Thu)
by nix (subscriber, #2304)
[Link] (4 responses)
Posted Feb 5, 2021 14:57 UTC (Fri)
by netghost (guest, #54048)
[Link] (3 responses)
Posted Feb 5, 2021 19:49 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Feb 19, 2021 16:41 UTC (Fri)
by netghost (guest, #54048)
[Link] (1 responses)
So Redhat/Ubuntu or whatever distributions are not "doing things with other people" by your definition, because they are compiling packages themselves. Oh, and all the Gentoo users.
I am surprised by the amount of rationality in your posts.
Posted Feb 19, 2021 21:29 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
That's an odd conclusion. There is a big difference between people who compile something on their own for their own use and people who compile things specifically to make it available to others. Distributions do the latter. If a core library isn't supported by any major distribution, that by definition limits it's usage very much to the select few who choose to do it on their own. That is the current status of the LibreSSL and that is what LWN is covering.
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
That's an inversion of how licence compatibility work.LibreSSL languishes on Linux
For a licence x to be compatible with GPLv2/3, it must be compatible with both v2 and v3.
Since v2+ is a potentially infinite list of licences, no licence is compatible with it except a subset of itself.
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
https://lists.debian.org/debian-devel/2020/10/msg00168.html
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
</wqw>
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
You still can work around it by issuing backdated certificates. I think that window is going to close in 2 years, though.
I know about DANE, it's not a solution. A more realistic solution is DNS stapling, basically instead of the regular X509 the certificate the server supplies the DNSSEC-signed replies all the way up to the root zone. The client then just validates the signature chain.
LibreSSL languishes on Linux
LibreSSL languishes on Linux
If you want to blame somebody for the fact that HTTP out of the box wasn't secure, I recommend blaming Tim.
LibreSSL languishes on Linux
As network sniffing increased, people started to worry about security. Fortunately ssh (incl. -X) arrived, making most of the above issues moot.
But the WWW was still (mostly) limited to plain HTTP...
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
Certs signed by official CAs don't actually guaranty that you are communicating with the entity that you think you are.
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
Latacora recommendation 2018 not considering Mbed TLS
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
See e.g. https://lists.exim.org/lurker/message/20200706.050711.4b8...
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
not possible to install both OpenSSL and LibreSSL on the same system
Because they have the same soname presumably. There are certainly ways around that if someone really wanted to install both. We have the source code. We also have lots of ways to coax linkers into doing things that upstream didn't anticipate.
However, I'd rather have my system use neither than both on balance.
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
https://www.cvedetails.com/vulnerability-list/vendor_id-9...
https://www.cvedetails.com/product/383/Openssl-Openssl.ht...
OpenSSL has 10x more CVEs from 2015 comapred to LibreSSL, not to mention many OpenSSL CVEs are more much dangerous. It is very obvious that LibreSSL's work is indeed EFFECTIVE and if you has to choose a openssl compatible solution with better security, LibreSSL is a better choice as of today.
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux
LibreSSL languishes on Linux