6 ms·
Microsoft Go 1.24 FIPS changes
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- infogulch 2y ago"What the heck is Microsoft Go?" > This repository produces a modified version of Go that can be used to build FIPS 140-2 compliant applications. Our goal is to share this implementation with others in the Go community who have the same requirement, and to merge this capability into upstream Go as soon as possible. It is also the default 'golang' package on Azure Linux 3.0. Microsoft Go fork: https://github.com/microsoft/go https://github.com/microsoft/go Issue discussing FIPS implementation: https://github.com/golang/go/issues/69536 https://github.com/golang/go/issues/69536
- nick__m 2y agoIs Azure Linux 3.0 a rebranding of CBL-mariner
- dfcarpenter 2y agoYes - https://www.phoronix.com/news/Microsoft-Azure-Linux https://www.phoronix.com/news/Microsoft-Azure-Linux
- cpuguy83 2y agoSort of... AzureLinux is a rebranding from CBL-Mariner. But 3.0 is an actual new version of the distro with newer packages (like going from Ubuntu 22.04 to 24.04, as an example).
- deleted 2y ago[deleted]
- yalue 2y agoMicrosoft 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 common practice in "normal" Go libraries. One thing I do appreciate is how the relevant issue in the upstream Go repo says: "A number of companies must comply with them, for example as part of a broader FedRAMP compliance posture. (If that's not you, you can ignore this. Run!)" [1] Apparently I'm just not the target audience. Sounds like I'm correct in assuming it's security theater at best, and an avenue for new backdoors at worst. [1] https://github.com/golang/go/issues/69536 https://github.com/golang/go/issues/69536
- deleted 2y ago[deleted]
- AaronFriel 2y agoThe 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-compliant TLS, but you have to make sure all of your libraries also use those algorithms. No rational person is going to vendor their entire dependency tree and maintain forks of the entire universe to swap `crypto/tls` and `net/http`. Well, some of these contracts are big enough to justify it, but whew, what a waste. The FIPS compliant Go builds from Microsoft and now Go 1.24 make it a lot easier to check that box and unless a package implemented their own TLS stack it's easy to attest that the software uses FIPS validated crypto modules. Without that, good luck trying to sell to gov and highly regulated institutions in financial and health.
- dagss 2y agoWouldn't declaring the "replace" directive in go.mod once take effect for all the dependencies?
- tptacek 2y agoIIRC, the FIPS-compliant Go crypto project was a Filippo Valsorda joint. I hate it, but I'm glad someone sane managed it.
- John23832 2y ago> "was a Filippo Valsorda joint" I like the reference.
- pvg 2y agohttps://github.com/golang/go/issues/69536?ref=words.filippo.io https://github.com/golang/go/issues/69536?ref=words.filippo.... https://words.filippo.io/dispatches/fips-hkdf/ https://words.filippo.io/dispatches/fips-hkdf/ Thought one of the Filippo/Go/FIPS posts had a big thread but doesn't look like it and/or can't find it.
- FiloSottile 2y agoI'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 stakeholders, the rest were funded by Geomys for the benefit of the Go community. There are some details now at https://go.dev/doc/security/fips140 https://go.dev/doc/security/fips140, but we're going to write a proper blog post once the module gets on the CMVP In Process list. tl;dr is that it should soon take a single environment variable to transparently build against a FIPS 140-3 validated module which is just a slightly out of date version of the same Go standard library everyone else is using. (AFAIK this is the first non-JVM memory safe FIPS 140 module!)
- Twirrim 2y agoI'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.
- 2y ago
- lordofgibbons 2y agoI've been using Go for about 10 years and this the first time I've heard of "Microsoft Go"
- deleted 2y ago[deleted]
- qmuntal 2y agoAuthor here. Microsoft is a soft Go fork mostly for internal Microsoft needs, but some projects outside of Microsoft use it as well due to it's good FIPS 140 story. I expect some of these users to switch back to Google's Go now that it will also ship with a FIPS-140 crypto stack.
- tetraodonpuffer 2y agoAny plans to use it for the managed azure istio so that can be used in FEDRAMP environments?
- Maksadbek 2y agoout of curiosity: what problems do you solve with this fork at Microsoft and why not C# ?
- porjo 2y agoAlso not to be confused with Microsoft Surface Go: https://en.m.wikipedia.org/wiki/Surface_Go https://en.m.wikipedia.org/wiki/Surface_Go
- AaronFriel 2y agoThe 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 https://dave.cheney.net/2016/01/18/cgo-is-not-go) - using boringcrypto and requiring CGO_ENABLED=1 could be a blocker. Not using system libraries meant that getting all of the software to agree on internal certificate chains was a chore. Go was in a pretty weird place. Whether FIPS 140 is actually a good target for cryptography is another question. My understanding is that FIPS 140-1 and 140-2 cipher suites were considered by many experts to be outdated when those standards were approved, and that FIPS 140 still doesn't encompass post quantum crypto, and the algorithms chosen don't help mitigate misuse (e.g.: nonce reuse).
- qmuntal 2y agoAuthor here. The macOS support currently uses cgo, but we are trying to make it cgo-less in Go 1.25, just as already happens on Windows. The goal is to allow pain-free cross-compilations from Linux to macOS.
- tptacek 2y agoWhether 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.
- MisterTea 2y ago> It's a thing you only do when you are forced to by some requisitions process. We're going through a FIPS compliance project right now and it's nothing more than a miserably expensive set of check boxes. Contractor they hired is incompetent so that isn't helping either.
- lantastic 2y agoDoes this mean FIPS-enabled software never runs as such in production (or at all) in environments where it is supposedly mandated?
- mkl95 2y agoIs this used anywhere outside of Azure?
- deleted 2y ago[deleted]
- manacit 2y agoI 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 designed to be released.
- jeffbee 2y ago> 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.
- jrockway 2y agoWhy under the table? Seems like someone like Canonical could just outright do the auditing itself.
- MisterTea 2y agoI 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...
- jeffbee 2y agoThis is interesting, but in this moment it is impossible to take any aspect of the FIPS program seriously. To get FedRAMP contracts you must meet FIPS 140-2 or -3! Or, you can just change your 4chan handle to "BigBalls". That's also acceptable.
- er4hn 2y agoThere's a few issues here. The dash version, 140-2 or 140-3 is the major version of the standard. You can only certify against -3 right now. Within the standard there are four level, 1 - 4 with 1 being the lowest and 4 being the highest. So a full cert descriptor would be something like "FIPS 140-3 Level 2". In order to get that you need to hire a certification lab to verify what you did and from there the government processes it. That processing, reading paperwork and asking a couple questions, takes over a year at this point which is where a significant issue is. This is also a prereq to FedRAMP, which is a whole new set of paperwork and checkbox compliance that adds debatable quality. I can understand the need to prevent unsafe solutions, but the current process is so slow and expensive that it makes selling useful things to customers that require FIPS a huge PITA.
- axus 2y ago"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?
- wahern 2y agoAlthough 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.
- killjoywashere 2y agoPlease, does this make it possible for me to send an email from Outlook to GMail encrypted using US government PKI?
- dstroot 2y agoTIL there are multiple flavors of Golang including “Microsoft Go”. Wow - I’ve been away from Golang too long. I was initially shocked and then kind of sad that Go is not so simple anymore.
- Tempest1981 2y agoIs the fragmentation due to FIPS 140-2 alone? Or are there other differences? Why couldn't the crypto changes be rolled into mainstream Go?
- cpuguy83 2y agoThe crypto changes are being rolled into mainstream Go, just that mainstream Go does not want the openssl/SCOSSL/SymCrypt parts.
- Tempest1981 2y agoAh, thanks. This reply also had more FIPS details: https://news.ycombinator.com/item?id=42966945 https://news.ycombinator.com/item?id=42966945
- gtirloni 2y agoI have been following Go for a while and didn't know that either.
- arp242 2y agohttps://github.com/microsoft/go/blob/microsoft/main/patches/0008-remove-long-path-support-hack.patch https://github.com/microsoft/go/blob/microsoft/main/patches/... Upstream Go tricks Windows into enabling long path support by setting an undocumented flag in the PEB. The Microsoft Go fork can't use undocumented APIs, so this commit removes the hack. There is no documented way to enable long path support from within the process, so this this is a breaking change for the Microsoft Go fork. Note that the Go standard library makes a best effort to support long paths by using the `\\?\` prefix when possible, so this change should only affect long relative paths, which can't be used with the `\\?\`. lol?
- thebeardisred 2y agoHow is this different to Red Hat's process of using OpenSSL instead of Go's crypto libraries? That's how they've been doing it for quite a while - https://developers.redhat.com/blog/2019/06/24/go-and-fips-140-2-on-red-hat-enterprise-linux https://developers.redhat.com/blog/2019/06/24/go-and-fips-14...