Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patch OpenSSL on November 1 to avoid “critical” security vulnerability

globalsign.com

Post reply on HN
Print view View original

41–50 of 217 posts

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#41

Post by fulafel »

stigz wrote: post #31
fulafel wrote: post #17

Earlier quoted context omitted.

The start has happened, but it's happening unevenly with different users. Lots of TLS servers (in reverse proxies but also in backend apps and even Apache httpd[1]) are in memory safe languages. For example Go, while not totally memory safe, has shipped their Go-implemented crypto/tls library for a long time. (And also had some crypto correctness bugs - reminding us that memory safety is "necessary but not sufficient…

Speaking of go, it looks they will be patching this as well. https://groups.google.com/g/golang-announce/c/dRtDK7WS78g

Yep, this is interesting, I wonder what we can deduce about the nature of the bug from the fact that 2 separate implementations, one that's mostly memory safe, are impacted. (Of course Go didn't announce it's about the same thing, so it might be random, or might be some security research that found different bugs)

Might it be a crypto bug, or logic bug (eg in x.509)? Is there code that's used by both OpenSSL and Go (eg assembly implementations of algorithms both imported or modeled after a reference)?

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#43

Post by pyuser583 »

29athrowaway wrote: post #14
pyuser583 wrote: post #11

Earlier quoted context omitted.

Is Ada memory safe? I don’t think it is.

It is still a significant upgrade in terms of safety over C.

The main argument against Ada is you can achieve a higher level of safety/convenience using C++ frameworks and code analysis tools.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#44

Post by shandor »

woodruffw wrote: post #22
mmwelt wrote: post #9

> And by widely leveraged, I mean almost completely ubiquitous, if you’re using HTTPS, chances are you’re using OpenSSL. Almost everyone is. This is probably a bit of an exaggeration. There are quite a few other SSL implementations that actually are also "widely leveraged"[1]. In particular, LibreSSL was forked and cleaned up after Heartbleed. Google uses BoringSSL. GnuTLS is widely used and unrelated to OpenSSL. [1]…

Is GnuTLS widely used? People bring it up, but I've never actually seen it in a codebase (and I deal with a lot of x509 + PKCS code). I've seen more wolfSSL and mbedTLS than GnuTLS.

How is wolfSSL/SSH? I have come across them a couple of times, but not having anyone/anything ”famous” behind them when compared to GNUtls or mbedtls always made me somewhat wary.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#45

Post by hotcoffeebear »

sullivanmatt wrote: post #25

Ubuntu 22.04 & RHEL 9 are the major distros impacted. Docker images built on ubuntu:latest will also be impacted. The latest releases of Alpine/Debian/AL2 are all not impacted, they use 1.1.x lineage.

That’s the reason Fedora 37 is still in beta (read that they will ship it with kernel 6.0 & gnome 43.1 as well)

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#47

Post by speedgoose »

timdoug wrote: post #30
speedgoose wrote: post #20

Earlier quoted context omitted.

Not OS or browser but my SSH servers use Teleport and my HTTPS servers use Traefik or Caddy. Caddy, Traefik, and Teleport are written in Golang and not using OpenSSL. It’s a start.

I adore Go, but it seems to be impacted too: https://groups.google.com/g/golang-announce/c/dRtDK7WS78g

Indeed, it doesn’t sound like a coincidence.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#48

Post by saghm »

woodruffw wrote: post #22
mmwelt wrote: post #9

> And by widely leveraged, I mean almost completely ubiquitous, if you’re using HTTPS, chances are you’re using OpenSSL. Almost everyone is. This is probably a bit of an exaggeration. There are quite a few other SSL implementations that actually are also "widely leveraged"[1]. In particular, LibreSSL was forked and cleaned up after Heartbleed. Google uses BoringSSL. GnuTLS is widely used and unrelated to OpenSSL. [1]…

Is GnuTLS widely used? People bring it up, but I've never actually seen it in a codebase (and I deal with a lot of x509 + PKCS code). I've seen more wolfSSL and mbedTLS than GnuTLS.

From looking at my currently installed packages, there are quite a few that depend on gnutls: ffmpeg, gnupg, libcups, vlc, and wget look like the ones that would be most well known. It's possible that they only use it as an option, but normally I'd expect it to only be an optional dependency if that were the case. I haven't looked at any of their codebases though, so no idea what they use it for!

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#49

Post by fulafel »

eastbound wrote: post #7

November 1st is a bank holiday in France, so a lot of sysadmins won’t be happy and systems will be vulnerable.

This is most likely but another possibility is that it was coordinated to happen on a bank holiday so systems can be dated with less impact from service outages.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#50

Post by yjftsjthsd-h »

29athrowaway wrote: post #15
yjftsjthsd-h wrote: post #12

Earlier quoted context omitted.

Are there TLS implementations in Ada that have a track record? I don't think that remark was aimed at the language, only pointing out that writing a new TLS library in a safer language is not exactly a trivial expenditure of resources.

The track record of OpenSSL = memory management vulnerabilities. Vulnerabilities that are preventable. Google: openssl "use-after-free" site:cvedetails.com/cve It's time to accept that C is not the tool for the job. Good programmers still make mistakes and now we have tools to catch most of those mistakes. In Rust many of those errors become compile-time errors.

That's one possible reading of the situation, certainly. Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in. Unfortunately TLS libraries are thin enough on the ground that we can't really pick out patterns. It's like saying that microkernels are bad because HURD has serious issues; it could be true, but comparing by the well-known problem child isn't necessarily a good way to tell.
Post reply on HN