## Overview FIPS compliance is a requirement for the US Govt to utilize a piece of software. It is required for any [FISMA](https://www.nist.gov/programs-projects/federal-information-security-management-act-fisma-implementation-project) or FedRAMP system, and [cannot be waived](https://csrc.nist.gov/projects/cryptographic-module-validation-program). In order for GitLab to be directly usable within the US Govt, we need to be compliant. A brief overview of FIPS may be found in this [Wikipedia article](https://en.wikipedia.org/wiki/FIPS_140-2). ## Next steps We need to: 1. [ ] Estimate the effort to address the areas of our product that utilize encryption 1. [x] Compare effort against business case for FIPS, and determine if we should move ahead with becoming FIPS compliant ## Areas that utilize encryption In discussions with internal and external parties, it seems the most critical areas to ensure are FIPS compliant those relating to encryption at rest, and in transit. ### Encryption at rest The current proposal is to utilize cloud provider tools to handle this requirement, for example: * AWS RDS encryption: https://aws.amazon.com/rds/features/security/#Encryption_of_Data_at_Rest * AWS EBS encryption: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html * AWS S3 encryption: https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html * AWS ElastiCache encryption: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/at-rest-encryption.html It is worth noting that all of these services can be FIPS compliant per Amazon: https://aws.amazon.com/compliance/fips/ ## Encryption in transit The work here falls into two main areas, GitLab services and dependencies like Postgres. We can rely on cloud provider settings for FIPS compliant versions dependencies, similar to above, but we will need to implement FIPS compliance with our own services that we have built. ### GitLab services Areas of our product that utilize encryption and transmit data over the wire: * [x] Git over SSH - https://gitlab.com/gitlab-org/gitlab/-/issues/295645 * [x] Git over HTTPS - https://gitlab.com/gitlab-org/gitlab/-/issues/295923 * [x] NGINX - https://gitlab.com/gitlab-org/gitlab/-/issues/296014 * [ ] Rails/Sidekiq - https://gitlab.com/gitlab-org/gitlab/-/issues/296015 * Auth modules (AD/LDAP, Kerberos, Omniauth) * [ ] [GitLab Pages daemon](https://gitlab.com/gitlab-org/gitlab-pages) - https://gitlab.com/groups/gitlab-org/-/epics/6948 * - [x] GitLab Runner - https://gitlab.com/gitlab-org/gitlab/-/issues/296017 * [Elasticsearch indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer) - https://gitlab.com/gitlab-org/gitlab/-/issues/296018 * [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) - https://gitlab.com/gitlab-org/gitlab/-/issues/296019 * Object storage proxy * Web terminal proxy ## Other considerations We also have a few areas that use MD5 hashing, which is disabled on FIPS systems: * [ ] SSH key fingerprints: https://gitlab.com/gitlab-org/gitlab-ce/issues/20502 https://gitlab.com/gitlab-org/gitlab-ce/issues/37899 * [ ] License verification: https://gitlab.com/gitlab-org/gitlab-ee/blob/v10.5.0-ee/ee/app/models/license.rb#L205 * [ ] Omnibus verifies integrity of many sources using MD5: https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/config/software ## FIPS Standard 140-2 or 140-3 Currently FIPS 140-2 is the requirement for programs like FedRAMP. However that is slated to change, potentially next year, as it is being replaced by FIPS 140-3. In doing some research, it looks like it makes the most sense to pursue 140-2 support now, as many of the tools have not been updated yet for 140-3. (For example, the tools to be FIPS compliant for golang) ## FIPS Information Since we will have different teams evaluating FIPS compliance, we should strive to maintain a common set of FAQs, libraries, and other information. Let's use this page in the documentation: * https://docs.gitlab.com/ee/development/fips_compliance.html * https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/fips_compliance.md ### FIPS validated libraries This section is intended to serve as a common area to list FIPS validated libraries that may prove useful to the team in exploring how to achieve FIPS compliance. * OpenSSL FIPS: https://www.openssl.org/docs/fips.html * Ruby * Generally recommended to compile/use against the FIPS version of OpenSSL * Golang * RedHat go-tools (likely better option): https://developers.redhat.com/blog/2019/06/24/go-and-fips-140-2-on-red-hat-enterprise-linux/ * golang with BoringCrypto: https://go.googlesource.com/go/+/refs/heads/dev.boringcrypto.go1.8/README.boringcrypto.md ### Important FIPS settings * Rails has a setting to disable MD5 usage: https://github.com/rails/rails/pull/31289 * Unfortunately it looks like some parts of ActiveStorage may still use MD5: https://github.com/rails/rails/issues/34443