[HN Gopher] Microsoft Go 1.24 FIPS changes
___________________________________________________________________
Microsoft Go 1.24 FIPS changes
Author : ingve
Score : 58 points
Date : 2025-02-06 19:03 UTC (3 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| infogulch wrote:
| "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
|
| Issue discussing FIPS implementation:
| https://github.com/golang/go/issues/69536
| nick__m wrote:
| Is Azure Linux 3.0 a rebranding of CBL-mariner
| dfcarpenter wrote:
| Yes - https://www.phoronix.com/news/Microsoft-Azure-Linux
| yalue wrote:
| 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 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
| AaronFriel wrote:
| 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-
| 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 wrote:
| Wouldn't declaring the "replace" directive in go.mod once
| take effect for all the dependencies?
| jerf wrote:
| "Is there a reason that a better package requires a fork of the
| entire runtime rather than just, say, a normal Go package?"
|
| I think at the time that would have been the only way to make
| it so any in-the-wild 3rd party code you want to use would use
| the FIPS-compliant libraries anytime someone imported
| "crypto/whatever" from the standard library.
|
| I haven't tested the workspaces functionality [1] to see if it
| allows you to override standard library functionality, but in
| principle something either very like that, or slightly tweaked,
| would be enough that you could just use standard Go with a
| particular text file dropped into place and some libraries to
| override the standard library now.
|
| But yeah, if you didn't even know this fork existed, you're not
| in the target audience. tptacek or someone else who really
| knows their stuff can Cunningham's Law me if I'm wrong, but my
| impression is that FIPS has a track record of rigidly demanding
| very medium levels of security, possibly including some rigidly
| poor security choices, and if you don't have a need to be in
| compliance, you can and should do much better by using newer
| and better options than what it mandates.
|
| [1]: https://go.dev/doc/tutorial/workspaces
| tptacek wrote:
| IIRC, the FIPS-compliant Go crypto project was a Filippo Valsorda
| joint. I hate it, but I'm glad someone sane managed it.
| pvg wrote:
| https://github.com/golang/go/issues/69536?ref=words.filippo....
|
| 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.
| John23832 wrote:
| > "was a Filippo Valsorda joint"
|
| I like the reference.
| FiloSottile wrote:
| 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
| 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, 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 wrote:
| 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.
| BoppreH wrote:
| 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!
| dolmen wrote:
| I think that Filippo deserves a bit more than a beer. He
| has business setup for true sponsorship.
|
| https://words.filippo.io/full-time-maintainer/
| raggi wrote:
| Do you anticipate that:
|
| > When GODEBUG=fips140=only is used, in addition to the
| above, cryptographic algorithms that are not FIPS 140-3
| compliant will return an error or panic. Note that this mode
| is a best effort and can't guarantee compliance with all FIPS
| 140-3 requirements.
|
| Will need to be more complete/certain in order to pass
| certification? My gut says it would based on the
| requirements, but I don't know how the auditors would respond
| in practice.
| lordofgibbons wrote:
| I've been using Go for about 10 years and this the first time
| I've heard of "Microsoft Go"
| qmuntal wrote:
| Author 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 wrote:
| Any plans to use it for the managed azure istio so that can
| be used in FEDRAMP environments?
| AaronFriel wrote:
| 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 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 wrote:
| Author 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 wrote:
| _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.
| MisterTea wrote:
| > 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 wrote:
| Does this mean FIPS-enabled software never runs as such in
| production (or at all) in environments where it is supposedly
| mandated?
| tptacek wrote:
| There are people here better positioned to answer than than
| I am. We've said "no" to customers who asked for this.
| prerok wrote:
| 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.
| lantastic wrote:
| FIPS and "be secure" aren't necessarily a full overlap:
| there's plenty of ways to be secure that isn't even
| allowed in FIPS, so you need to actively disable that set
| if you run FIPS mode (depending on libraries used, this
| may e.g. disqualify hardware intrinsics because it was
| not covered by CMVP, creating potentially material
| performance consequences).
|
| If you're already compliant (implying you are using FIPS
| compliant crypto in all situations), the matter is
| tautological.
| mfer wrote:
| 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.
| westurner wrote:
| 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?_
| mkl95 wrote:
| Is this used anywhere outside of Azure?
| manacit wrote:
| 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 designed to be released.
| jeffbee wrote:
| > 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 wrote:
| Why under the table? Seems like someone like Canonical could
| just outright do the auditing itself.
| MisterTea wrote:
| 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...
| jeffbee wrote:
| This 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 wrote:
| There'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 wrote:
| "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 wrote:
| 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.
| killjoywashere wrote:
| Please, does this make it possible for me to send an email from
| Outlook to GMail encrypted using US government PKI?
| dstroot wrote:
| TIL 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.
___________________________________________________________________
(page generated 2025-02-06 23:00 UTC)