💾 Archived View for freedombone.net › blog › the-cloudflare-conundrum.gmi captured on 2020-11-07 at 00:40:40. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
As an extra firewall option I've added the ability to block Cloudflare IP addresses within Freedombone [1]. For now I'm not going to make it the default and instead leave it as an option within the *freedombone-sec* command. The reason for that is because Cloudflare has become so pervasive that blocking it by default could break things.
Cloudflare is an expanding centralized system implementing a sort of internet based firewall or *firewall by proxy*. It has sometimes been described as *"the lazy admin's firewall"*. So if you're a corporate sysadmin on a six figure salary and you'd rather spend time on the golf course than configuring servers then your go-to solution is to proxy your traffic through Cloudflare and hope that they do a good job of filtering any incoming bogons [2]. The trouble is that this proxied Man In The Middle [3] situation then turns into a hazard, because it's a point at which third parties can exert control without the knowledge of sender or receiver (Alice and Bob in the security lingo. Cloudflare would be Eve). Unless you absolutely trust Cloudflare, it breaks the transport layer security.
One problem on the immediate horizon is that Gitlab will be using Cloudflare soon [4]. If cloning a repo goes through a Cloudflare proxy then there is very obvious potential for targeted nefariousness to occur. Imagine a government issuing a secret order to insert a bug into a repo when it is cloned by a certain IP address, without the knowledge of the git hosting company.
At present the Gitlab mirror of Freedombone is being used for updates, so I may need to rethink that and move it elsewhere.