MVC: SSL & TLS Certificate check
Problem to solve
Applications that serve traffic using invalid or expired certificates mean that end-users can't be sure if they're talking to the real application or an imposter. This means that they will not know when an attacker is intercepting their connection and will trust the application less.
It is difficult to know when an application's certificates have expired or are not valid until after the fact without requiring manual work. A recent example of the need for this capability is the recent outage of Teams being caused by expired SSL certificates.
Intended users
- Delaney (Development Team Lead)
- Sidney (Systems Administrator)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
Further details
This should be applicable for users who are using GitLab to deploy and manage their applications, not pointing to 3rd-party sites. We shouldn't intentionally exclude 3rd-party sites, but we don't need to focus on them specifically for this issue.
Proposal
Periodically check the certificates that are being used to serve traffic for a user's application hosted with GitLab. If the certificates are invalid or expired, notify the user so they can then manually take action. This should not need to be triggered in a pipeline by a code commit, as scanning should be performed even if users take no action after initially configuring the SSL certificate checking.
Minimal requirements to make the MVC Viable
- Provide users a way to enable TLS/SSL monitoring for a GitLab-hosted application.
- A new screen under
Security & Compliance
menu for configuration
- A new screen under
- Periodically run a scan on the given URLs to check the status of their certificates
- Proposal: weekly
- Performance note: If we do all jobs at the same time each interval, that is a large performance impact. Instead, start the period based on when the user sets up the configuration so we get a staggered start.
- Provide notice to users if a certificate is invalid or expired.
- For the purposes of what is considered "invalid" or "expired", desired behavior is to closely replicate what an end-user using a web browser would see if they manually visited the site. That is, if the page would display a warning in Firefox or another browser about certs, this alert should be sent.
- Valid Root CAs should be those that are installed by default in web browsers
-
Where is the best place to surface this alert? Can we leverage an existing notification system in GitLab, rather than build something new?
- For the purposes of what is considered "invalid" or "expired", desired behavior is to closely replicate what an end-user using a web browser would see if they manually visited the site. That is, if the page would display a warning in Firefox or another browser about certs, this alert should be sent.
- Usage ping implemented to record:
- How many projects have scanning enabled
- Number of scans that found no issues
- Number of scans that found issues
UX
- Scanning should happen periodically without requiring a user to manually trigger the scan. Scanning should also not require a code commit nor an MR.
- Report should live under a new section in Security & Compliance
- Report should list:
- Each detected SSL/TLS cert
- Validity Status
- Expired
- Invalid cert
- Expiring soon (proposal: within 90 days)
- Valid
- Expiration time
- Any other relevant metadata
-
Coordinate with UX on designs for this screen
- Some initial concepts are attached under the Design tab
Future work
Permissions and Security
To view the report & controls, users should have the same permissions as are required to view the Security Dashboard.
Documentation
Create documentation to show users how to enable the settign for their projects as well as how to view and interpret the results. Add a section that describes how to remedy the most common problematic situations related to their certificates (expiration, invalid signature)