quic-go: A Pure Go QUIC Stack That Now Speaks FIPS 140-3
A production-ready QUIC implementation in pure Go. FIPS 140-3 Starting with v0.60, quic-go supports use in FIPS 140-3 environments when built with Go 1.26 or newer, using Go standard library cryptography for the QUIC code paths relevant in FIPS mode; see FIPS140.md for details.
At a glance
- What is it?
- quic-go delivers RFC 9000 QUIC and HTTP/3 in pure Go, and with v0.60 it adds a FIPS 140-3 mode built on Go 1.26's standard library crypto. This review covers its protocol scope, integration path, and the limits of its FIPS story.
- Who is it for?
- Adopt quic-go if you need a pure Go QUIC or HTTP/3 client/server and you can commit to the Go toolchain version it requires, especially for FIPS environments where v0.60+ with Go 1.26+ is your path. Avoid it if you need a C-based QUIC stack for maximum performance or if you must stay on an older Go release.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What quic-go Solves and Who Needs It
The README lists a long set of RFCs and drafts, which tells you the project tracks the QUIC ecosystem beyond the base spec. That includes DPLPMTUD (RFC 8899) for path MTU discovery, QUIC Version 2 (RFC 9369), and qlog event logging. For a developer, this means you are not just getting a minimal QUIC; you get features that matter for real-world deployment, like handling NAT rebinding and PMTU changes. The target user is an engineer building a network service that needs low-latency, multiplexed connections, and who wants to stay in the Go ecosystem.
The Architecture: Pure Go, But with a FIPS Twist
For an engineer, this architecture means you get the benefits of a pure Go stack, but you must understand the FIPS boundary. The FIPS mode is not a separate build of quic-go; it is a build configuration of Go that quic-go then uses. The practical implication is that you need to verify your Go build is FIPS-enabled, and quic-go will then use those crypto primitives. This is a clean approach, but it also means you cannot use quic-go's FIPS mode on older Go versions. The README is explicit: Go 1.26 or newer is required for FIPS support. That is a hard constraint that will affect upgrade planning.
Getting It Running: Commands and Config Keys
The README does not show a code example, so I cannot give you a ready-to-run snippet. But the package structure is clear: the 'quic' package for QUIC, 'http3' for HTTP/3, and 'qlog' for event logging. If you are integrating quic-go, you will likely start with the 'http3' package for a web server, or the 'quic' package for custom protocols. The documentation at quic-go.net is the place to find actual code.
FIPS 140-3: The New Feature and Its Constraints
The FIPS support is not a separate fork or a set of build tags within quic-go; it is a property of the Go runtime. This means the burden of validation falls on the Go toolchain, not on quic-go. For an organization, this is both a benefit and a risk. The benefit is that you get FIPS compliance without maintaining a separate crypto library. The risk is that Go's FIPS mode may not be accepted in all environments, or may not cover all QUIC-specific operations. The README says 'relevant in FIPS mode', which leaves room for interpretation. You must verify with FIPS140.md and potentially with your own security team.
A Real Limitation: Go Version Churn and FIPS Boundaries
The wrong tool case: if you need to interoperate with a non-Go QUIC implementation that uses non-standard extensions, or if you need to run on a Go version older than 1.26, quic-go may not be suitable. Also, if you require a formal FIPS validation certificate for the entire stack, quic-go's reliance on Go's standard library may not satisfy that, depending on your auditor. The README does not claim quic-go itself is FIPS-validated; it says it 'supports use' in FIPS environments. That distinction is critical.
Alternatives: How They Differ in Approach
Another alternative is to use a QUIC implementation in a different language entirely, such as Rust's quinn, but that requires a language change. For Go developers, the realistic choice is between quic-go and a CGO-based binding. The decision hinges on your tolerance for CGO and your need for FIPS. If you need FIPS and you are already on Go 1.26+, quic-go is the path of least resistance. If you need maximum performance and you are comfortable with CGO, a C-based stack might be better. The README does not provide performance numbers, so you must benchmark in your own environment.
Maintenance and Upgrade Cost
The license is MIT, which means you can embed quic-go in proprietary software. There are no explicit patent grants, but MIT is a standard permissive license. The project does not appear to have a CLA or contributor agreement, which simplifies contributions. The maintenance cost is not trivial: the Go version churn is a real burden. If you are not prepared to upgrade Go frequently, quic-go may introduce friction.
Editorial conclusion
Adopt quic-go if you need a pure Go QUIC or HTTP/3 client/server and you can commit to the Go toolchain version it requires, especially for FIPS environments where v0.60+ with Go 1.26+ is your path. Avoid it if you need a C-based QUIC stack for maximum performance or if you must stay on an older Go release. Before deploying, verify your exact Go version against the FIPS140.md requirements and test interoperability against a non-Go QUIC peer, since the README does not list a formal conformance test suite.
Community notes