FIPS compliance umbrella issue

[qmuntal]

This is the tracking issue for FIPS work which must be done before saying we are FIPS compliant. The list will grow over time and some of the bullets will have their own issue.

• Several crypto APIs are not backed by boring/openssl because they are not part of the FIPS spec. Decide if we want to panic or not if someone tries to use them.

  • crypto/des: The package documentation states that DES is cryptographically broken and should not be used for secure applications.
  • crypto/md5: The package documentation states that MD5 is cryptographically broken and should not be used for secure applications.
  • ed25519: ED5519 is cryptographically secure but not yet approved by FIPS 140-2.

• Several Go crypto packages are not backed by boring/openssl because they don't implement a high level crypto algorithm but are just entities/helpers to be used with other crypto packages. Decide if we want to panic or not if someone tries to use them.

  • crypto/rand
  • crypto/x509
  • crypto/elliptic
  • crypto/cipher

• Several FIPS 140-2 crypo algorithms are still using Go crypto instead of boring/openssl. We should open issues upstream or start a discussion in golang-nuts.

  • sha512.Sum512_224 and sha512.Sum512_256: Both supported by openssl 1.1.1 and higher. Should we panic if using 1.0.2 and 1.1.0?

• New crypto APIs: openssl-fips branch adds new ecdsa and rsa methods #280

• Don't force tlsfips but make it opt-in

[qmuntal]

The big question is: Should we panic when using a non-FIPS compliant API?

My initial bet is that we shouldn't, at least by default, as it would be too disruptive. Yet I see it has value as an opt-in feature activated with an env variable. This way our users can at least run their integration tests, or even their prod services, in this strict mode.

[jaredpar]

In general the crypto team has given us the guidance of don't enforce FIPS policy in the framework. Essentially flipping to FIPS should never be a disruptive change. It's the job of the framework to have FIPS compliant crypto where possible then the individual teams need to make decisions about what algorithms to or not to use.

For example at the start I would make sure we list all of these algorithms as not being FIPS compliant because they don't go through OpenSSL then the individual teams have to make decisions about using it.

[qmuntal]

@jaredpar another question for the crypto board:

Go implemented its own TLS stack using crypto primitives that in our case are implemented by openssl. FIPS 140-2 adds additional restrictions to what cipher-suites, tls versions and elliptic curves can be used with TLS communications. For example, SHA1 is a FIPS-approved algorithm but cannot be used to sign a TLS certificate. The problem is that openssl does not know why an application is requesting a SHA1 signature, so it cannot block it.

To solve this issue, Go has implemented in its boringcrypto branch a package called crypto/tls/fipsonly, and by just importing it the Go TLS stack forces to use and accept only FIPS-approved algorithms for TLS.

In official go, the use of this package is optional, and applications have to opt-in via importing it. So it could be that someone is using openssl in fips mode but yet not being FIPS compliant in its TLS stack.

Fedora fork imports this package by default when running in FIPS mode, and there is no way to opt-out.

The questions is: Which approach should we follow? Forcing a FIPS-approved TLS stack is the safest approach in terms of security. On the other hand we are limiting the compatibility of applications build using our fork, as not all TLS clients support TLS v1.2 nor the newest cipher suites.

My take on this is that we should follow official go approach and make it opt-in.