Here's the official place where these are announced, if you feel a little uneasy getting urgent security advisories from tweets and blogs:<p><a href="https://mta.openssl.org/mailman/listinfo/openssl-announce" rel="nofollow">https://mta.openssl.org/mailman/listinfo/openssl-announce</a>
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.
> And by widely leveraged, I mean almost completely ubiquitous, if you’re using HTTPS, chances are you’re using OpenSSL. Almost everyone is.<p>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.<p>[1] <a href="https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations" rel="nofollow">https://en.wikipedia.org/wiki/Comparison_of_TLS_implementati...</a>
When I execute an ldd at /usr/bin/ssh I get<p><pre><code> libssl.so.10 => /lib64/libssl.so.10
libssl3.so => /lib64/libssl3.so
libnss3.so => /lib64/libnss3.so
</code></pre>
What puzzles me is that I am using libssl.so.10 and libssl3.so at the same time. libssl3.so belongs to the nss package and not to the openssl package. Am I affected?
when will browsers learn and just replace ssl/tls with one line of code to verify that the public key portion of the URL matches the session established by the website? C is only a hundredth of the problem here (that 100th is still big). its ironic that this news was brought to us by a scammer's corporate blog
This is supposedly the commit which fixes the bug <a href="https://github.com/openssl/openssl/commit/3df6aed7826640d944da382f78af5ab87ea790db" rel="nofollow">https://github.com/openssl/openssl/commit/3df6aed7826640d944...</a>