Thanks for the update on LibreSSL. Last time I looked at it, they were still in version 1.x, and still only supported on BSD-based systems. I see they're at version 3.x now.

I wonder how much of this is still the case about support on Linux?...

https://lwn.net/Articles/841664/

There's also an overwhelming level of "this-is-fine"-ism in the industry, so as long as OpenSSL isn't a complete dumpster fire at the moment, people aren't willing to invest in alternatives, regardless of how drop-in-ready they may be (which is apparently still a debatable point with LibreSSL on Linux, or at least still was 2 years ago, when the above article was written).

Longer term, maybe a complete re-imagining is what the industry will need to move forward. Most companies and developers are motivated more by new features than by correctness or security, sadly.

Gilbert

On 2023-02-22 3:12 p.m., Adam Thompson wrote:

Bob Beck et al. from the OpenBSD project already "secured" OpenSSL, with the result being called LibreSSL.  It's drop-in compatible for many applications, but does require recompiling.  That team did a number of presentations on it, and apparently you can still hear the swearing echoing late at night when it's quiet...

The OpenSSL team, however, appear to be rather resistant to help. Serious NIH syndrome.  Also they're more focused on preserving backwards compatibility than correctness or security.  And also don't respond well to criticism, from what I've seen.

All the large orgs you mentioned already have their own OpenSSL-replacement projects in-house, some of them public.  None of those are even remotely drop-in replacements, they're re-imagninings of what a secure-connection library should be.

-Adam

*From:* Roundtable roundtable-bounces@muug.ca on behalf of Gilbert Detillieux Gilbert.Detillieux@umanitoba.ca *Sent:* February 22, 2023 2:17 PM *To:* Continuation of Round Table discussion roundtable@muug.ca *Subject:* Re: [RndTbl] Fw: [SECURITY] Fedora 36 Update: openssl-3.0.8-1.fc36 As if we didn't already have enough issues with OpenSSL, what with buffer overrun vulnerabilities in new/recent code*, and more direct coding flaws (pointer free/dereference and such) that were recently announced**.

You'd think with the combined wealth and resources of Alphabet/Google, Apple, and Microsoft, they'd find it in their best collective self-interest to fund a project to replace this garbage with some, you know, actually secure code.

Sigh!

Gilbert

https://nsfocusglobal.com/openssl-multiple-buffer-overflow-vulnerability-not... https://nsfocusglobal.com/openssl-multiple-buffer-overflow-vulnerability-notice/

** https://www.openssl.org/news/secadv/20230207.txt https://www.openssl.org/news/secadv/20230207.txt https://linuxsecurity.com/features/urgent-openssl-security-advisory https://linuxsecurity.com/features/urgent-openssl-security-advisory

https://www.lansweeper.com/vulnerability/8-vulnerabilities-in-openssl-could-... https://www.lansweeper.com/vulnerability/8-vulnerabilities-in-openssl-could-lead-to-system-crashes/

https://www.ibm.com/support/pages/security-bulletin-multiple-vulnerabilities... https://www.ibm.com/support/pages/security-bulletin-multiple-vulnerabilities-openssl-affect-aix     (Many of the above do mention the side-channel attack too.)

On 2023-02-22 1:51 p.m., Trevor Cordes wrote:

...

Oh joy, "password timing" attacks come to SSL.

e.g. CVE-2022-4304  Published 2023-02-08T20:15:00 A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack.

Begin forwarded message:

Date: Wed, 22 Feb 2023 11:09:09 +0000 (GMT) From: updates@fedoraproject.org To: package-announce@lists.fedoraproject.org Subject: [SECURITY] Fedora 36 Update: openssl-3.0.8-1.fc36

---

Fedora Update Notification FEDORA-2023-a5564c0a3f 2023-02-22 11:06:32.699863

---

Name        : openssl Product     : Fedora 36 Version     : 3.0.8 Release     : 1.fc36

• Thu Feb  9 2023 Dmitry Belyavskiy dbelyavs@redhat.com - 1:3.0.8-1

• Rebase to upstream version 3.0.8

Resolves: CVE-2022-4203     Resolves: CVE-2022-4304     Resolves: CVE-2022-4450     Resolves: CVE-2023-0215     Resolves: CVE-2023-0216     Resolves: CVE-2023-0217     Resolves: CVE-2023-0286     Resolves: CVE-2023-0401

On 2023-02-22 14:17, Gilbert Detillieux wrote:

You'd think with the combined wealth and resources of Alphabet/Google, Apple, and Microsoft, they'd find it in their best collective self-interest to fund a project to replace this garbage with some, you know, actually secure code.

1) not having to pay for it; and

2) having a scapegoat for stuff that goes sideways.

Both sound awful to me, but I am not a CEO for a reason...

On 2023-02-22 15:12, Adam Thompson wrote:

The OpenSSL team, however, appear to be rather resistant to help. Serious NIH syndrome.  Also they're more focused on preserving backwards compatibility than correctness or security.  And also don't respond well to criticism, from what I've seen.

Amusing, isn't it? Every once in a while someone shows up smearing the OpenBSD developers  for *reasons*, but as far as I can tell they strike a good balance between stability - avoiding changes for the sake of it -  while regularly dropping the dead weight to make things secure and to move forward. A reasonable compromise, if you will.

On 2023-02-22 15:37, Gilbert Detillieux wrote:

Longer term, maybe a complete re-imagining is what the industry will need to move forward.  Most companies and developers are motivated more by new features than by correctness or security, sadly.

Let me present the Schrödinger's SysAdmin:

- If things break, well, it's your fault. You shouldn't have messed with anything, it was working before. Don't fix what isn't broken. - If things work, are you even doing anything? If nothing is breaking, you must be useless.

It's hard to sell something that, when done, won't change anything as far as most people are concerned. No new apparent features; instead, potential for disruption and costs. All of that to protect from the *threat* - as in something that may or may not happen - of an attack.

At best, you can try and argue that something /could have happened/, but didn't. Even if you can prove it, more often than not, someone could easily think you're exaggerating to prove a point.

The optimist wishes executives could see the light.  The realist knows that, as long as someone other than themselves can be blamed, more often than not they won't let you do what you must.... until the moment where you /should have done it. /Then, it's /your fault./ Or, instead, they just buy insurance for it, pretend no one could ever have seen it coming, and move along.

Yes, some places do see past all the cynicism, and have some accountability. But we would not have landed where we are if that weren't the exception to the rule, so it is what it is. Let's hope it finds a way to go that does not involve a huge BANG.