fips-tls-probe

Overview ¶

Command fips-tls-probe is a portable acceptance check for a Go toolchain's TLS stack. It completes a real TLS 1.2 and TLS 1.3 handshake in-process and exits non-zero if either fails, hangs, or panics.

It is meant to run immediately after a FIPS Go toolchain is built, in any pipeline that compiles one from source (gitlab-build-images, gitlab-omnibus-builder, CNG). It catches toolchain regressions that pass a plain "go build" but break TLS at runtime, such as the golang-fips "tls: HKDF-Expand-Label invocation failed unexpectedly" panic that shipped non-functional Gitaly TLS in every GitLab 19.2.x FIPS build.

Exit codes:

0  Both handshakes completed.
1  A handshake failed or hung, or -require-fips was set and no FIPS backend
   is active.
2  Unrecovered panic (Go's runtime exit code). The probe deliberately does
   not recover panics: a crypto-backend panic, like the golang-fips
   HKDF-Expand-Label one, is the exact failure this probe exists to surface,
   and a crash is the loudest possible signal.

Build it with the toolchain under test, with the backend switched on:

# golang-fips (boringcrypto); GOLANG_FIPS=1 activates the OpenSSL backend
GOEXPERIMENT=boringcrypto CGO_ENABLED=1 GOLANG_FIPS=1 \
    go run -tags fips gitlab.com/gitlab-org/labkit/v2/cmd/fips-tls-probe -require-fips

# native Go FIPS 140-3 module (Go 1.24+)
GOFIPS140=v1.0.0 go run -tags fips gitlab.com/gitlab-org/labkit/v2/cmd/fips-tls-probe -require-fips

With -require-fips it asserts the FIPS backend is actually active, so a green run proves the toolchain's FIPS TLS works rather than merely that it links. The probe has no third-party dependencies, so a pipeline can also vendor the single file and run it with "go run".