Skip to content

GitLab Next

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab FOSS GitLab FOSS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 2
    • Merge requests 2
  • Requirements
    • Requirements
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #46391

Closed
Open
Created May 15, 2018 by Drew Blessing@dblessingMaintainer

Expose Net::LDAP cipher configuration

Zendesk: https://gitlab.zendesk.com/agent/tickets/96126 (internal)

Customer is subject to FIPS and has to restrict which TLS protocol versions and ciphers are used in its services. As a result, after an upgrade of GitLab and by proxy, OpenSSL, there are no longer default ciphers in common and GitLab could not connect to their LDAP server. We implemented a hack on their system, specifically setting ciphers that the GitLab LDAP client could use to connect. After this communication worked again.

We need to expose ciphers configuration that Net::LDAP uses inside tls_options. We already expose ca_file and ssl_version so adding ciphers would be similar.

It would be great if we can ship this in a patch, or slip it into 10.8 otherwise this customer's instance will break again upon upgrade. I'm surprised we haven't run into this issue with other customers with similar compliance constraints, but undoubtedly we will encounter is sooner or later.

@stanhu What release do you think this is appropriate for? I can put together a MR.

Assignee
Assign to
Time tracking