More-aggressive HSTS with preloading for gitlab.com
Right now we set the Strict-Transport-Security
-header without specifying includeSubDomains; preload;
We should consider doing this and submitting gitlab.com to hstspreload.org.
The gitlab.com domain should have no service, that is not reachable via HTTPS. This is an additional protection against rouge redirects, that might be served by a malicious entity, that could result in http://gitlab.com being redirected to another domain.
Once gitlab.com is in the preloading list, every supported browser will go straight for the https version, even if a user enters http://.
Possible impact: Any non-HTTPS service under a gitlab.com subdomain will no longer be reachable. (But there should not be a service that does not offer HTTPS, too! - If there is, fix that.)
We should also consider doing the same for the gitlab.net domain.
cc @gitlab-org/security @gitlab-com/gl-infra for opinion.