TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

SSL/TLS Security Enhancements

10 posts · Jan 2015 – Sep 2024

What this trail covers

GitLab has consistently focused on enhancing the security of its platform, particularly concerning SSL/TLS configurations. This includes addressing vulnerabilities and providing guidance on upgrading encryption. This post details the deprecation of TLS 1.0 and 1.1 on GitLab.com and its API by December 15, 2018, due to known security issues and PCI DSS 3.1 compliance mandates. It identifies specific client incompatibilities (Git Credential Manager for Windows, older Git on Red Hat, JGit/Java < JD). In GitLab 17.7, the version of OpenSSL for Linux packages will be updated to OpenSSL 3. This upgrade changes the types of SSL connections the GitLab server can create and receive. For self-managed users, all outbound connections from the GitLab instance will need to meet the minimum requirements of TLS 1.2 or above, along with at least 112-bit encryption for TLS certificates. Outbound connections not meeting this standard will fail. Inbound TLS connections to the GitLab server already require TLS 1.2 by default, as of GitLab 12.0.

All GitLab trails
  1. GitLab Linux package being upgraded to OpenSSL 3 in GitLab 17.7This post announces the upgrade of OpenSSL to version 3 for GitLab's Linux packages in version 17.7. This upgrade mandates TLS 1.2 or above and at least 112-bit encryption for outbound connections from self-managed instances. It provides guidance for administrators to check external integration compatibility and recommends remaining on GitLab 17.6 if TLS configurations cannot be updated in time. The change is driven by security interests and the end-of-life of OpenSSL 1.1.1.
  2. GitLab's response to curl and libcurl security vulnerabilityThis post details GitLab's investigation and response to CVE-2023-38545, a heap buffer overflow vulnerability in curl/libcurl via the SOCKS5 protocol. GitLab confirmed no SOCKS5 usage in its GitLab.com and GitLab Dedicated environments, thus no direct impact. For self-managed customers, it advises referencing the curl security advisory for exposure assessment and upgrading to curl version 8.4.0. The investigation involved proactive scoping and analysis of SOCKS5 usage across the GitLab environment.
  3. New OpenSSL 3.0 vulnerabilities: What you need to know to find and fix themThis post details the discovery and mitigation of two OpenSSL 3.0 vulnerabilities (CVE-2022-3786 and CVE-2022-3602) affecting X.509 email address buffer overflows. It explains how the vulnerabilities work, the risk to organizations using OpenSSL 3.0, and confirms that GitLab's production systems were not impacted. It also notes that GitLab's DAST analyzer was updated to patch the vulnerable library.
  4. The Consul outage that never happenedThis post details a near-outage incident caused by an expired self-signed TLS certificate for Consul. It describes the troubleshooting process, including validating the problem by temporarily disabling certificate validation and the subsequent cluster instability. The planning phase involved evaluating options like replacing the CA, using system store certificates, or disabling date validation. The team chose to disable date validation as an incremental step to avoid immediate downtime, demonstrating an iterative approach to security. The post also highlights the challenges of coordinating a simultaneous restart across a distributed team and the use of the `at` command for precise timing. The incident underscores the importance of production readiness reviews, monitoring, and robust certificate management practices.
  5. TLS 1.0 and 1.1 support ended on GitLab.com and APIThis post announces the discontinuation of TLS 1.0 and 1.1 support on GitLab.com and its API, mandating TLS 1.2 for all client connections. It details specific client incompatibilities with TLS 1.2, including Git-Credential-Manager-for-Windows prior to 1.14.0, Git on older Red Hat versions, JGit/Java releases < JDK 8, and older Visual Studio versions, providing upgrade paths for each. It also notes that self-managed installations will track these changes in a separate issue for a future release.
  7. TLS 1.0 and 1.1 support ending on GitLab in 2018This post announces the deprecation of TLS 1.0 and 1.1 support on GitLab.com and the GitLab API by December 15, 2018. It provides a canary environment ([canary.gitlab.com](https://canary.gitlab.com/)) for users to test their integrations and browsers for TLS 1.2 compatibility. It also lists specific client incompatibilities, including Git-Credential-Manager-for-Windows prior to 1.14.0, Git on older Red Hat versions, JGit/Java releases < JDK 8, and older Visual Studio versions, advising users to update their clients.
  8. GitLab to deprecate support for TLS 1.0 and TLS 1.1 by end of 2018This post announces the deprecation of TLS 1.0 and 1.1 on GitLab.com and its API by December 15, 2018, citing security vulnerabilities (e.g., Heartbleed) and PCI DSS 3.1 compliance. It details identified client incompatibilities with TLS 1.2 and provides specific upgrade paths for affected software like Git Credential Manager for Windows, Git on Red Hat, JGit/Java, and Visual Studio.
  9. Tutorial: Securing your GitLab Pages with TLS and Let's EncryptThis post introduces the practical implementation of securing GitLab Pages with TLS/SSL certificates obtained from Let's Encrypt. It details the benefits of TLS/SSL beyond just transaction security, explains how to obtain free certificates, and provides a step-by-step tutorial for configuring custom domains on GitLab Pages to use these certificates. This significantly enhances the security and trustworthiness of user-hosted static websites.
  10. GitLab.com and LogjamThis post details the decision to remove DHE suites from GitLab.com's cipher suite, prioritizing ECDHE for forward secrecy with major browsers and clients, while acknowledging the impact on older clients like Android 2.3.7, Java 6, and OpenSSL 0.9.8. The SSL Labs score improved from B to A. Recommended configurations for omnibus-gitlab packages and GitLab installations from source were also updated.
  11. Security advisory for Logjam vulnerabilityThis post addresses the Logjam vulnerability by detailing its impact on GitLab and GitLab.com. For self-managed installations, it provides instructions on how to generate 2048-bit DH groups using `openssl dhparam` and configure Nginx via `gitlab.rb` for both omnibus packages (version 7.11.0 and up, and prior versions) and source installations. For GitLab.com, it states that 1024-bit DH groups are in use and that enabling 2048-bit DH params is being investigated due to compatibility issues with older Java-based clients.
  12. Responding to GhostThis post details the immediate actions taken by GitLab to address the Ghost vulnerability in glibc. It outlines the process of updating OS packages (`apt-get upgrade`, `yum update`) and the recommendation to reboot servers. For high-availability setups, it describes using a DRBD-based clustered setup with failover to minimize downtime during the reboot process.