openssl VS OpenSSL

JRuby doesn't use the official openssl gem which contains C extensions that compile against libopenssl, but instead uses jruby-openssl. There are a few minor compatibility issues with jruby-openssl. I've ran into the missing EC.generate method before. In theory CRuby's openssl OpenSSL::PKey::EC.generate creates a new OpenSSL::PKey::EC object and calls #generate_key, but trying that in JRuby produces a smaller EC key implying there's some data missing from the EC key, so I'm not sure if that approach is equivalent.

I would edit ossl.c and copy some code from Ruby OpenSSL commit 8e98d2e. This might be easier than building an old version of OpenSSL.

The used digest algorithm. I created an issue with the OpenSSL gem, see https://github.com/ruby/openssl/issues/474

ruby-install 0.8.3 has been released. This version explicitly pins the homebrew openssl dependency to [email protected]. OpenSSL 3.0 was released this month and is now available in homebrew. Unfortunately, ruby’s openssl bindings are still working on OpenSSL 3.0 support, so attempting to compile any current ruby version against OpenSSL 3.0 from homebrew will result in a compilation error. Until all actively supported versions of Ruby support OpenSSL 3.0, ruby-install will continue to compile against [email protected] on macOS with homebrew.

As an example, the Amazon implementation doesn't refer to gcc's[1] and clang's[2] "zero_call_used_regs" to zeroise CPU registers upon return or exception of functions working on crypto secrets. OpenSSL doesn't either.[3] firedancer _does_ use "zero_call_used_regs" to allow gcc/clang to zeroise used CPU registers.

As another example, the Amazon implementation also doesn't refer to gcc's "strub" attribute which zeroises the function's stack upon return or exception of functions working on crypto secrets.[4][5] OpenSSL doesn't either.[3] firedancer _does_ use the "strub" attribute to allow gcc to zeroise the function's stack.

Is there a performance impact? [6] has the overhead at 0% for X25519 for implementing CPU register and stack zeroisation. Compiling the Linux kernel with "CONFIG_ZERO_CALL_USED_REGS=1" for x64_64 (impacting all kernel functions) was found to result in a 1-1.5% performance penalty.[7][8]

[1] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute...

[2] https://clang.llvm.org/docs/AttributeReference.html#zero-cal...

[3] https://github.com/openssl/openssl/discussions/24321

[4] https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Common-Type-At...

[5] https://gcc.gnu.org/onlinedocs/gcc/Stack-Scrubbing.html

[6] https://eprint.iacr.org/2023/1713.pdf

[7] https://www.phoronix.com/review/zero-used-regs/5

[8] https://lore.kernel.org/lkml/20210505191804.4015873-1-keesco...

you can check the CHANGES.md [1] or here [2]

[1] https://github.com/openssl/openssl/blob/master/CHANGES.md

If you're going to use a custom local domain name, you might as well use a self-signed SSL certificate. I'll use OpenSSL for this:

Are you facing the notorious ERR_OSSL_EVP_UNSUPPORTED error in your Node.js applications? This error is a common stumbling block that occurs due to changes in cryptographic operations handling introduced with Node.js version 17. The root of the problem lies in the default configuration of OpenSSL in newer Node.js versions, which restricts the use of certain algorithms. Fortunately, there are effective solutions to overcome this error, ensuring your development process remains smooth and uninterrupted.

ENV OPENSSL_PREFIX=/opt/openssl ENV SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt WORKDIR /tmp RUN git clone --branch OpenSSL_1_0_2n https://github.com/openssl/openssl.git RUN cd openssl RUN ./config shared --prefix=$OPENSSL_PREFIX --openssldir=$OPENSSL_PREFIX/ssl RUN make RUN make install RUN rvm install 2.6.0 -C --with-openssl-dir=$OPENSSL_PREFIX ENV PATH /usr/local/rvm/bin:$PATH RUN rvm --default use ruby-2.6.0 ENV PATH /usr/local/rvm/bin:/usr/local/rvm/rubies/ruby-2.6.0/bin:$PATH ENV GEM_HOME /usr/local/rvm/rubies/ruby-2.6.0/lib/ruby/gems/2.6.0

Today, April 7th, 2024, marks the 10-year anniversary since CVE-2014-0160 was published. This security vulnerability known as "Heartbleed" was a flaw in the OpenSSL cryptography software, the most popular option to implement Transport Layer Security (TLS). In more layman's terms, if you type https:// in your browser address bar, chances are high that you are interacting with OpenSSL.

At this point I pretty much understand the entire process on how the xz backdoor came to be: its execution stages, extraction from binary "test" files etc. But one thing puzzles me: how can the ifunc mechanism be used to replace something like RSA_public_decrypt? Granted this probably stems from my lack of understanding of ifunc, but I was under the impression that in order for the ifunc mechanism to work in your code, you have to explicitly mark specific function with multiple implementations with __attribute__ ((ifunc ("the_resolver_function"))). Looking at the source code of the RSA function in question, ifunc attribute isn't present:

https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_crpt.c#L51

So how does the backdoor actually replace the call? Does this means that the ifunc mechanism can be used to override pretty much anything on the system?

OpenSSL and Go crypt/tls has no support yet, so none of the webservers that depend on them support it. Apache, Nginx, and Caddy, they all need upstream ECH support first.

- https://github.com/openssl/openssl/issues/7482

- https://github.com/openssl/openssl/pull/22938

- https://github.com/golang/go/issues/63369