Issue #13681 has been updated by rinzler (Colton Jenkins).


rhenium (Kazuki Yamaguchi) wrote:
> rinzler (Colton Jenkins) wrote:
> > Ah ok, do you know what will happen to openssl::digest then given it uses the same? Curious if that plans to be refactored upon 1.1.x I could do the same with this. If not then this doesn't make much sense.
> 
> See ext/openssl/ossl_digest.c -- it doesn't use the low level API like
> SHA1_Update() at all and uses the EVP API consistently.

Yep, I reviewed and noticed it doesn't attempt to access EVP_MD_CTX directly at all. Just passes it around.
> 
> > It is beginning to sound like this shouldn't be used and decoupling digest from openssl is a better way forward?
> > I'll probably continue to use this patch locally given our customers are desiring FIPS and rewriting all gems is a very large undertaking, but curious of your thoughts?
> 
> OK, I've just learnt about FIPS 140. So what is important for you is
> that the implementation of those algorithms is FIPS-certified (i.e.,
> OpenSSL); I didn't think of that case. Although I'm pretty sure it
> wasn't originally for that purpose that ext/digest prefers to use
> OpenSSL but purely for the performance. Refactoring ext/digest to use
> the EVP API seems the best direction, then.
> 
Yes, if openssl with FOM is present then utilizing EVP interface would make life much easier.
Rewriting ext/digest to use EVP would be a larger task to accomplish given what is currently in place works off of alg##_CTX directly.
How is larger work typically done here? Just one large patch or? I'd like to help if possible.
> > I think I'll move forward with adding in the above recommendations and place a condition for OPENSSL_VERSION < 1.1.
> 
> No such a condition would be needed, you shouldn't have to extract the md_data
> field from an EVP_MD_CTX.
Right, if alg##_CTX wasn't passed in then no need to interact with EVP_MD_CTX. 
We would have to change how digest init/update/final signatures are called.


----------------------------------------
Feature #13681: Ruby digest init fails in FIPS mode when built against OpenSSL ~> 1.0.1
https://bugs.ruby-lang.org/issues/13681#change-65631

* Author: rinzler (Colton Jenkins)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
When FIPS (https://en.wikipedia.org/wiki/FIPS_140-2) is enabled attempting to initialize any digest will kill the process due to https://github.com/openssl/openssl/commit/65300dcfb04bae643ea7b8f42ff8c8f1b1210a9e

Example,

~~~
> require 'digest'
> Digest::MD5.new
md5_dgst.c(75): OpenSSL internal error, assertion failed: Low level API call to digest MD5 forbidden in FIPS mode!

> require 'digest'
> Digest::SHA1.new
sha_locl.h(128): OpenSSL internal error, assertion failed: Low level API call to digest SHA1 forbidden in FIPS mode!
~~~

This patch will redefine alg##_Init to use the EVP interface. This allows the digest initialization to never die, but will fail when using a non FIPS algorithm (MD5).

Example,

~~~
irb(main):002:0> Digest::MD5.new
RuntimeError: disabled for fips
	from (irb):2:in `new'
	from (irb):2
	from /usr/local/bin/irb:11:in `<main>'
irb(main):003:0> Digest::SHA1.new
=> #<Digest::SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709>
~~~

---Files--------------------------------
add_evp_init_to_digests.patch (3.77 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>