Quoted post unavailable.
Or, instead of expecting people to go rewrite stuff for you, you could go switch to rustls. It literally costs zero money.
Patch OpenSSL on November 1 to avoid “critical” security vulnerability
21–30 of 217 posts
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#22> 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.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#23How many times does this have to happen before we start rejecting components written in unsafe languages?
Seven.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#24Quoted post unavailable.
Or, instead of expecting people to go rewrite stuff for you, you could go switch to rustls. It literally costs zero money.
Genuine question, should I prefer rustls or openssl for security in rust.
A reasonable number of crates let you switch between them with just a cfg flag, and when using them the only difference that makes it way to the user is security (and maybe performance), but I'm not sure which I should consider to be more secure?
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#25Ubuntu 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.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#26How many times does this have to happen before we start rejecting components written in unsafe languages?
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…
Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#27Earlier quoted context omitted.
Or, instead of expecting people to go rewrite stuff for you, you could go switch to rustls. It literally costs zero money.
Genuine question, should I prefer rustls or openssl for security in rust. A reasonable number of crates let you switch between them with just a cfg flag, and when using them the only difference that makes it way to the user is security (and maybe performance), but I'm not sure which I should consider to be more secure?
At this point we consider rustls about as secure or a little more. Ring is a high-quality set of primitives thats basically some carefully ported boringssl code, and both it and rustls have been around for a good while and have plenty of contributors. Tbh we like the lack of old legacy cruft (where most openssl bugs get found) as much as a memory-safe language, ditching all that ancient code we don't need really cuts down attack surface.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#28> 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.
widely? depends on your viewpoint, but there are quite few consumers (look at the right column) https://archlinux.org/packages/core/x86_64/gnutls/
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#29November 1st is a bank holiday in France, so a lot of sysadmins won’t be happy and systems will be vulnerable.
Spain, too.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#30Earlier quoted context omitted.
You first. What browser and OS are you posting from?
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