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.
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!
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.
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?
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.
FiloSottile | 24 days ago
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.
talideon | 23 days ago
You've made a whole bunch of people's jobs much, much easier, and I thank you all for that!
xilef | 24 days ago
You (plural) have done a good job. Thank you.
0x2ba22e11 | 23 days ago
Well done!
ngrilly | 24 days ago
It's amazing. Congrats, and thank you!!!
nickmonad | 23 days ago
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!
tuananh | 24 days ago
Go is using boringssl right? how did they fips certify it?
kokada | 23 days ago
No, this was the previously solution, the new one is a native Go implementation (so no CGO): https://go.dev/blog/fips140.
fs111 | 23 days ago
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.
df | 23 days ago
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.
xyproto | 24 days ago
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?
orib | 23 days ago
This is a downgrade on security, but allows use in some government contexts.
[OP] runxiyu | 23 days ago
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.
zaphar | 23 days ago
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.
fs111 | 23 days ago
It indeed is just compliance theater from what I can tell.
talideon | 23 days ago
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.
kwas | 24 days ago
USA MIC's contractors can now hire (more?) golang programmers and deliver software based on it.
fs111 | 23 days ago
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.