[go: up one dir, main page]
Skip to content

Investigate if/how Import TLS use follows/recommends best practice

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

See https://gitlab.com/gitlab-org/manage/import/backend/discussion/-/issues/9 for context

TLS protects confidentiality and integrity of information as it is transmitted. It is a common requirement in compliance frameworks (see references below).

Proposal

  • Identify what versions (or lack thereof) of TLS are permitted in Import / Export network requests (see also https://gitlab.com/gitlab-org/manage/import/backend/discussion/-/issues/11)
    • Also identify whether invalid/expired/untrusted/self-signed certificates are rejected
  • Identify if there is a legitimate use-case for weak TLS (e.g. self-hosted GitLab talking to a legacy ____ on premise, or enterprise proxies intercepting and resigning requests). (Product / Solution Architects might know)
  • Decide a path forward, e.g.:
    • Creating issues to document the risk
    • Creating issues to allow administrator configuration of TLS version enforcement
    • Creating issues to hard-code TLS version enforcement
      • e.g. in integrations like AWS, or GitHub, where we know they'll have the latest TLS

Progress

Import Source Sources supports plaintext HTTP? Source supports TLS < v1.2? Source supports weak ciphers? Expired certificates rejected? Improperly signed certificates rejected?
GitLab.com
GitLab self-hosted 1 Yes, it's the default
GitHub.com
GitHub Enterprise (self-hosted)
  1. Custom certificates are supported in omnibus. We should accept ones that are properly installed, and reject ones that aren't.

References

Edited by 🤖 GitLab Bot 🤖