4 ms·

> As a result of the complexity and requirements, we realized we would like to have a solution for CDN, WAF, and DDOS protection with one vendor. [emphasis mine

> As a result of the complexity and requirements, we realized we would like to have a solution for CDN, WAF, and DDOS protection with one vendor. [emphasis mine] Cloudflare will see All The Things™ as TLS termination at Cloudflare is required for Cloudflare to be able to analyze web traffic and block common attacks. Just based on that one sentence, it seems like a value play more than anything. That they care enough for the defense-in-depth is probably a good sign, but that also shows a bias in favor of security over privacy. Depending on your personal or corporate privacy preferences/politics, that may or may not be desirable, but it's also for you to decide if any resulting risks are acceptable. My hope is that Gitlab pressed Cloudflare on the process changes that took place after the WAF outage last year. --- (this comment has been heavily edited since it was originally published)

hartator 7y ago
I don’t think that’s true. You can serve your own SSL certificate through Cloudflare and they won’t be able to inspect it?
- eganist 7y ago
  > I don’t think that’s true. You can serve your own SSL certificate through Cloudflare and they won’t be able to inspect it? Unless there's been a serious homomorphic encryption breakthrough, it's impossible to impose layer 7 intrusion prevention if layer 6 encryption is passthrough. They subscribed to consolidate the listed offerings (CDN, WAF, DDoS protection). That WAF is mentioned at all is a tip that Cloudflare must decrypt and analyze Gitlab's traffic before re-encrypting it for delivery to Gitlab's application servers.
- judge2020 7y ago
  There are 2 different "use your own SSL" solutions at the moment (for enterprise): A. Uploading your own certificate - this just uploads it and CF still does HTTPS interception. B. Spectrum - Cloudflare will proxy the actual port 443 TCP connections (which might be the plan for SSH connections to GitLab that are not altssh.gitlab.com). The issue is that this only does layer 4 IP reputation DDOS protection; no WAF, etc is done so this most likely isn't what they will do for the main gitlab.com site.
  - T4cC0re 7y ago
    In the case of Cloudflare, there also is option C, "Keyless-SSL", where you control the key. (https://www.cloudflare.com/ssl/keyless-ssl/ https://www.cloudflare.com/ssl/keyless-ssl/) But that is irrelevant in our case. We opted to use Cloudflare Spectrum to facilitate our change. There is no way to mix Spectrum and non-Spectrum on one hostname, but Spectrum allows us to choose between TCP, HTTP, and HTTPS pipelines. While we intend to TCP proxy port 22 on gitlab.com and 443 on altssh.gitlab.com, this also allows us to use Cloudflare's HTTP(s) content processing pipeline on ports 80 and 443 on gitlab.com. In the latter case Cloudflare will be terminating TLS, performing WAF, CDN and Workers duty, then re-encrypt and send the request to our origin. You can look at some visualization of this here: https://gitlab.com/gitlab-com/gl-infra/readiness/tree/master/cloudflare#architecture https://gitlab.com/gitlab-com/gl-infra/readiness/tree/master...

hartator 7y ago

I don’t think that’s true. You can serve your own SSL certificate through Cloudflare and they won’t be able to inspect it?

eganist 7y ago
> I don’t think that’s true. You can serve your own SSL certificate through Cloudflare and they won’t be able to inspect it? Unless there's been a serious homomorphic encryption breakthrough, it's impossible to impose layer 7 intrusion prevention if layer 6 encryption is passthrough. They subscribed to consolidate the listed offerings (CDN, WAF, DDoS protection). That WAF is mentioned at all is a tip that Cloudflare must decrypt and analyze Gitlab's traffic before re-encrypting it for delivery to Gitlab's application servers.
judge2020 7y ago
There are 2 different "use your own SSL" solutions at the moment (for enterprise): A. Uploading your own certificate - this just uploads it and CF still does HTTPS interception. B. Spectrum - Cloudflare will proxy the actual port 443 TCP connections (which might be the plan for SSH connections to GitLab that are not altssh.gitlab.com). The issue is that this only does layer 4 IP reputation DDOS protection; no WAF, etc is done so this most likely isn't what they will do for the main gitlab.com site.
- T4cC0re 7y ago
  In the case of Cloudflare, there also is option C, "Keyless-SSL", where you control the key. (https://www.cloudflare.com/ssl/keyless-ssl/ https://www.cloudflare.com/ssl/keyless-ssl/) But that is irrelevant in our case. We opted to use Cloudflare Spectrum to facilitate our change. There is no way to mix Spectrum and non-Spectrum on one hostname, but Spectrum allows us to choose between TCP, HTTP, and HTTPS pipelines. While we intend to TCP proxy port 22 on gitlab.com and 443 on altssh.gitlab.com, this also allows us to use Cloudflare's HTTP(s) content processing pipeline on ports 80 and 443 on gitlab.com. In the latter case Cloudflare will be terminating TLS, performing WAF, CDN and Workers duty, then re-encrypt and send the request to our origin. You can look at some visualization of this here: https://gitlab.com/gitlab-com/gl-infra/readiness/tree/master/cloudflare#architecture https://gitlab.com/gitlab-com/gl-infra/readiness/tree/master...