Go is FIPS 140-3 certified
65 points by runxiyu
65 points by runxiyu
It was a journey! You can read more in last year’s post and we’ll publish a new post about the certificate soon.
As ever, if you don’t know you need FIPS 140-3 you don’t need FIPS 140-3, but if you do need it, I’m fairly confident Go is one of the easiest and most secure ways to achieve that. It was especially hard to preserve all the security (and convenience) we provide to other users despite the FIPS 140-3 rules, but I think we did a pretty good job at it.
You've made a whole bunch of people's jobs much, much easier, and I thank you all for that!
Congrats! I work with a large bring-your-own-cloud deployment that is going to need FIPs compliance in certain customer environments, but alas, we aren't using Go anywhere :( Maybe this could be a motivating change!
Nice! We did a deployment using the Red Hat FIPS Go build but I never liked that we had to use a whole different version of the Go stack to achieve FIPS.
A whole lot of products that sell to the US government are required to use FIPS (and don’t want to produce FIPS and non-FIPS variants), so this is a big deal for companies being able to adopt Go.
Which practical consequences are this likely to have? Will Go be more interesting for some companies or organizations now, or is this purely about security?
USA MIC's contractors can now hire (more?) golang programmers and deliver software based on it.
I'll tentatively say it's a net minus on security as you would not be able to use modern ciphers such as (X)ChaCha20-Poly1305.
Technically, if you are willing to put in the effort you can get an exception on the grounds that your choice is more secure and is safe. However most companies in practice are not willing to put in the effort so they just do the minimal thing and rely on on FIPS compliant because that's all their customer, the US govt, requires.
However most companies in practice are not willing to put in the effort so they just do the minimal thing and rely on on FIPS compliant because that's all their customer, the US govt, requires.
It indeed is just compliance theater from what I can tell.
I'd partially agree, but FIPS-140-3 is at least now tolerably modern. Having had to deal with FIPS-140-2, I was dead set against applying any of that outside of a production environment that didn't mandate it, but FIPS-140-3 is fine.
Where I work we have commercial and government offerings and FIPS is a hard requirement for the latter. We rely on Redhat doing the right thing for us with golang. That then results in binaries that can be used in either environment.
Go is using boringssl right? how did they fips certify it?
No, this was the previously solution, the new one is a native Go implementation (so no CGO): https://go.dev/blog/fips140.
No, the current FIPS compliance can be achieved by using the boringssl source tree but compiling against openssl instead. openssl is compliant. That is what Redhat does for RHEL and we rely on that for all our workloads. Basically the same as this https://github.com/golang-fips/go
This new thing is all native go. No more openssl or any other hackedy-hack, just the standard library.