Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Go 1.24 FIPS changes

devblogs.microsoft.com

Post reply on HN
Print view View original

31–40 of 70 posts

Re: Microsoft Go 1.24 FIPS changes

#31

Post by MisterTea »

jeffbee wrote: post #17
manacit wrote: post #15

I worked on a project about 4-5 years ago that required operating in a FIPS 140-2 environment and this was a huge problem, happy to see there's multiple different investments into doing this right. Same with OpenSSL offering an easy-to-snag FIPS-certified implementation. We had to buy what felt like bootleg Canonical OpenSSL binaries, and Go looked like building some speculative forks that clearly had not been design…

> We had to buy what felt like bootleg Canonical OpenSSL binaries Isn't this the entire FIPS scam? You have to do whatever your auditor says, even if it's ridiculous, and they are getting paid under the table by vendors.

I am glad I am not the only one who thinks FIPS is a scam along with the contractor industry that has spawned up around it. Our VC hired contractor tried the same thing, walk in and hand us his "master plan" without any input from us and collect his 75k. His plan would never work in our environment and when we presented our list of issues he was dismissive and the project has barely progressed. Thank god we meticulously document all of our communications in emails which we have had to show in meetings with the president to explain why we are past our deadline with no concrete plan or hardware ordered. Total mess...

Re: Microsoft Go 1.24 FIPS changes

#32

Post by mfer »

AaronFriel wrote: post #13

The upstream Go 1.24 changes and macOS support using system libraries in Microsoft's Go distribution are really significant for the large ecosystem of startups trying to sell to institutions requiring FIPS 140 certified cryptography. For a variety of reasons - including "CGo is not Go" ( https://dave.cheney.net/2016/01/18/cgo-is-not-go ) - using boringcrypto and requiring CGO_ENABLED=1 could be a blocker. Not using s…

For those building applications with FIPS 140 crypto the primary concern is compliance rather than security. There are many organizations (e.g., US federal) that have requirements for it.

The latest version is FIPS 140-3 and is more up to date.

Note, binaries made for FIPS 140 with OpenSSL dynamically linked do not run on Alpine. While I've not looked at the Microsoft go/openssl compiler, it's worth testing its output across distros/versions as different distros have different versions of glibc and openssl.

Re: Microsoft Go 1.24 FIPS changes

#33

Post by lantastic »

tptacek wrote: post #25
AaronFriel wrote: post #13

The upstream Go 1.24 changes and macOS support using system libraries in Microsoft's Go distribution are really significant for the large ecosystem of startups trying to sell to institutions requiring FIPS 140 certified cryptography. For a variety of reasons - including "CGo is not Go" ( https://dave.cheney.net/2016/01/18/cgo-is-not-go ) - using boringcrypto and requiring CGO_ENABLED=1 could be a blocker. Not using s…

Whether FIPS 140 is actually a good target for cryptography is another question Answer to that question: it is not. It's a thing you only do when you are forced to by some requisitions process.

Does this mean FIPS-enabled software never runs as such in production (or at all) in environments where it is supposedly mandated?

Re: Microsoft Go 1.24 FIPS changes

#34

Post by westurner »

AaronFriel wrote: post #13

The upstream Go 1.24 changes and macOS support using system libraries in Microsoft's Go distribution are really significant for the large ecosystem of startups trying to sell to institutions requiring FIPS 140 certified cryptography. For a variety of reasons - including "CGo is not Go" ( https://dave.cheney.net/2016/01/18/cgo-is-not-go ) - using boringcrypto and requiring CGO_ENABLED=1 could be a blocker. Not using s…

From https://news.ycombinator.com/item?id=28540916#28546930 :

  GOLANG_FIPS=1
From https://news.ycombinator.com/item?id=42265927 :

> Chrome switching to NIST-approved ML-KEM quantum encryption" (2024) https://www.bleepingcomputer.com/news/security/chrome-switch...

From https://news.ycombinator.com/item?id=41535866 :

>> Someday there will probably be a TLS1.4/2.0 with PQ, and also FIPS-140-4?

Re: Microsoft Go 1.24 FIPS changes

#35

Post by tptacek »

lantastic wrote: post #33
tptacek wrote: post #25

Earlier quoted context omitted.

Whether FIPS 140 is actually a good target for cryptography is another question Answer to that question: it is not. It's a thing you only do when you are forced to by some requisitions process.

Does this mean FIPS-enabled software never runs as such in production (or at all) in environments where it is supposedly mandated?

There are people here better positioned to answer than than I am. We've said "no" to customers who asked for this.

Re: Microsoft Go 1.24 FIPS changes

#36

Post by Twirrim »

FiloSottile wrote: post #29
tptacek wrote: post #7

IIRC, the FIPS-compliant Go crypto project was a Filippo Valsorda joint. I hate it, but I'm glad someone sane managed it.

I'm not involved in the OpenSSL/CNG-based Microsoft Go fork. I've managed and implemented—along with Daniel McCarney, Roland Shoemaker, and Russ Cox—the native upstream Go validation mentioned in the intro, which is shipping in Go 1.24 and will be certified on Linux (amd64, arm64, ppc64le, s390x), Windows (amd64, arm64), macOS (arm64), and FreeBSD (amd64). The Linux operating environments were funded by various stake…

I'm so glad this is making its way in to Go properly now, and sort of baffled that this wasn't treated as a priority sooner by Google, given that they're operating within FIPS environments.

Re: Microsoft Go 1.24 FIPS changes

#37

Post by wahern »

axus wrote: post #30

"We evaluated changing Microsoft Go to use the new Go FIPS module rather than system libraries. However, we ultimately determined that this approach doesn’t align with Microsoft internal cryptography strategy and policies." Any good modern conspiracy theories about Windows system libraries for cryptography?

Although auditing rules have been loosened up in various respects, ultimately whenever code within the FIPS module boundary changes a new validation and certification process is supposed to be kicked off and tracked. For Microsoft itself it's obviously more convenient to manage 1 module rather than 2. But more importantly, many Microsoft customers depend on Windows providing compliant and certified cryptographic modules; they don't have to worry about it, period, except to keep their Windows installations updated. With built-in Go modules, that now becomes the problem of every individual organization. It's nowhere near as bad as 5+ years ago, when auditors were more strict about only using certified binary modules, which meant you often faced a Sophie's Choice when it came to bug fixes. Today the bar is more that you're using a code base that has been certified (i.e. built some binary that was certified), and when bug fixes are made will quickly be re-certified (in the interim you'll get forbearance). But it's still a greater process and change management burden than when you're just consuming a certified system library from a vendor who takes 100% responsibility for keeping it in a certified state, and which can be updated independently, without having to rebuild all your software.

While rebuilding your fleet of Go apps may be trivial in a technical sense, organizing and tracking deployment across an enterprise is less trivial. Tracking that your nodes are all running updated versions of Windows isn't trivial, either, but much easier.

FIPS is a PITA largely because of the change management burden. But that's precisely one of the biggest gaps in enterprise security. Keeping most of your installations up-to-date is easy; it's the long tail of stragglers and misfits that is the most difficult part. In that light, quibbling about algorithms is almost like bike shedding, though it's difficult to overestimate how much bad crypto is out there (see, e.g., last year's Okta bcrypt issue that is making the rounds again on HN). When people complain about having to use ECDSA P-256 instead Ed25519[1], I want to roll my eyes.

[1] Ed25519 finally became FIPS compliant only last year, there aren't many (any?) certified implementations, and in any event P-256 is just much more widely supported, especially in niches like HSMs, etc.

Re: Microsoft Go 1.24 FIPS changes

#38

Post by prerok »

lantastic wrote: post #33
tptacek wrote: post #25

Earlier quoted context omitted.

Whether FIPS 140 is actually a good target for cryptography is another question Answer to that question: it is not. It's a thing you only do when you are forced to by some requisitions process.

Does this mean FIPS-enabled software never runs as such in production (or at all) in environments where it is supposedly mandated?

I don't understand the question.

We created software and we wanted it to be secure (by ourselves). When it came to FIPS compliance, we had to pay for certification, but we were already compliant anyway, so it was only procedure.

It's definitely not as strict as the latest developments in crypto would demand, but it does cover the product in its entirety. Like, oh, you have encryption, but you have a backdoor here: not FIPS-2 compliant.

So, yes, plenty of software and products are FIPS compliant. And if it's mandated, then the provider is not chosen.

Re: Microsoft Go 1.24 FIPS changes

#39

Post by BoppreH »

FiloSottile wrote: post #29
tptacek wrote: post #7

IIRC, the FIPS-compliant Go crypto project was a Filippo Valsorda joint. I hate it, but I'm glad someone sane managed it.

I'm not involved in the OpenSSL/CNG-based Microsoft Go fork. I've managed and implemented—along with Daniel McCarney, Roland Shoemaker, and Russ Cox—the native upstream Go validation mentioned in the intro, which is shipping in Go 1.24 and will be certified on Linux (amd64, arm64, ppc64le, s390x), Windows (amd64, arm64), macOS (arm64), and FreeBSD (amd64). The Linux operating environments were funded by various stake…

I just wanted to say that we've adopted many of your projects at $DAYJOB, and it has been one of the best technical decisions we've made. So far I've used the Go crypto package, age, and more recently xwing. It all works flawlessly, and at every turn we have happy surprises (smooth cross-compilation, the Age plugin framework, typage, fast xwing revisions, your blog posts).

If we ever meet in person, I own you a beer!

Re: Microsoft Go 1.24 FIPS changes

#40

Post by dagss »

AaronFriel wrote: post #16
yalue wrote: post #6

Microsoft Go? I've used Go on windows for years now and this is the first I've heard of this fork. So it only exists because microsoft wants to have a crypto package that complies with an arbitrary regulation? Is there a reason that a better package requires a fork of the entire runtime rather than just, say, a normal Go package? It sounds like it requires cgo to call into third-party libraries, but that's already a…

The comment is accurate that if you don't need this, you can ignore it. It's likely not an avenue for backdoors. I wouldn't say it's security theater but it just isn't meaningful to most. As for why not a library? Go has a pretty big "batteries included" implementation for networking. For customers demanding FIPS compliance it isn't enough to say, write all of your own application code to use a package that does FIPS…

Wouldn't declaring the "replace" directive in go.mod once take effect for all the dependencies?
Post reply on HN