jruby / jruby-openssl

JRuby's OpenSSL gem
http://www.jruby.org
Other
45 stars 79 forks source link

FIPS-140 support #277

Open yweiy10 opened 1 year ago

yweiy10 commented 1 year ago

Hello,

This is a follow-up question for https://github.com/jruby/jruby-openssl/issues/259.

I'd like to invest some time here to verify if I can switch the bouncycastle jars to be fips-validated ones. My application is mainly in JRuby and we recently got a request for FIPS compliance. So I don't think I have another choice but to fix the jRuby-openssl and have a FIPS version of it at least. Is that right?

And for the development, I'd like to understand how I can test thoroughly after switching the bc dependencies. Is unit test in the codebase decent?

I also found that OpenSSL, which I believe is the base of JRuby-openssl is FIPS validated. So do you think there is a way that I can borrow some experience or impl from there?

Thanks for your help!

morneaut commented 1 year ago

I'm in the exact same situation and would like to explore a solution. I see that BouncyCastle has jars that could take the place of the older non-compliant jars.

kares commented 1 year ago

In theory this is possible but in practice this would need dedicated work (how much I do not know but I guess a minimum of a week or two) and thus someone would need to simply put in the hours.

yweiy10 commented 1 year ago

I did poke around and found that the api compatibility between bc and bc-fips are not as ideal as we expected. I did some quick diff comparison and it looks to me that more than 80% are different without considering the impl under the hood and it significantly destroys my confidence to make it even just compile with a short period of time.

yweiy10 commented 1 year ago

And the way I'm pursuing right now is through an encryption shim in my JRuby application. I would use another java security provider library, Conscrypt, to provide the encryption functionalities and answer all the encryption calls(luckily not that much) in my application.

kares commented 1 year ago

Yeah, I also thought it's not just .jar replacement and that JOSSL might need to build a level of indirection using some of the APIs.

Not sure about the scope of the whole thing, my initial time estimate this would take might be very optimistic and I do not see anyone understanding the code base committing to that much work here...