
Upcoming changes to our CDN for GitLab.com - ZeroCool2u
https://about.gitlab.com/blog/2020/01/16/gitlab-changes-to-cloudflare/
======
deeblering4
Is anyone else getting worried about the amount of the internet that is
proxied through cloudflare?

~~~
filmgirlcw
As opposed to the amount of the internet hosted by Amazon?

Like, I understand the argument, I’m just not sure why we get angsty about one
type of market dominance and not another.

~~~
AznHisoka
Amazon has no control over who can visit what website, for the most part. They
just host your site. Cloudflare on the other hands acts more like a
gatekeeper. They have more control over who can visit.

~~~
oarsinsync
Unless you're managing the webserver process yourself, Amazon has the exact
same level of control over who can visit your website as Cloudflare.

When you're managing the webserver yourself, they can still filter by IP as
they run the network. With a bit more effort (but this feels unlikely to be
happening wide-scale), they can still transparently MITM your connections as
the private keys are still stored on their infrastructure.

------
porker
I wonder how much Fastly's pricing impacted this?

OT but my clients are small players (10s of GB traffic a month); but they
value availability and low latency for their dynamic content. Fastly (and
varnish) are ideal for this, but every time I talk to Fastly about services
beyond the PAYG-CDN it's "min $2k/month", "$5k/month + fees".

I'd rather use them than Cloudflare, I've been accused of being a walking
advert for Fastly - but they are pushing me towards other providers and
proving actively hostile to small clients.

Good for them if they are raking it in from enterprise customers. But AWS
manages to cater for both ends of the market, and it's a shame to see good
services price themselves into "enterprise-only" territory.

~~~
jgrahamc
There's a comment below from a Gitlab employee that mentions the breadth of
the Cloudflare feature set as being key:
[https://news.ycombinator.com/item?id=22073753](https://news.ycombinator.com/item?id=22073753)

------
m4lvin
Does this mean GitLab.com will become unusable via Tor?

[https://support.cloudflare.com/hc/en-
us/articles/203306930-U...](https://support.cloudflare.com/hc/en-
us/articles/203306930-Understanding-Cloudflare-Tor-support-and-Onion-Routing)

~~~
T4cC0re
That is a very good question.

In general, what you can expect to see when visiting a Cloudflare site via Tor
is a CAPTCHA challenge to authenticate your browser to show you're not a bot.

As to whether we can enable the `Onion Routing` setting, which would cause
your browser to connect to Cloudflare via Tor and not via an exit-node, I
don't know if we may enable it. There might be some compliance issues with
that, which may prevent us from enabling that.

I have however created an issue on this for further investigation whether that
might be possible: [https://gitlab.com/gitlab-com/gl-
infra/infrastructure/issues...](https://gitlab.com/gitlab-com/gl-
infra/infrastructure/issues/8954)

~~~
jgrahamc
If you're using TBB then you should NOT expect to see a CAPTCHA from
Cloudflare at all. Unless the customer specifically wants to challenge Tor
users we do not challenge them just because they use TBB.

------
eat_veggies
What are the privacy implications of this? Will Cloudflare be able to see
GitLab traffic? Was/is Fastly able to before? And is there any reason to trust
one over the other?

~~~
IfOnlyYouKnew
I trust Cloudflare a whole lot more than Gitlab. CF makes all the right noises
around privacy for their 1.1.1.1 service, for example.

Gitlab is still the team that didn't notice that three of their three
independent backup mechanisms had not been working for weeks to months. And
while wholly cloning Github is legal, I started having serious doubts about
their ethical instincts when they repeatedly tried to incite people against
Github for cloning minor features.

Beyond that: it depends. I tend to believe large vendors are worse for privacy
of generic consumers, because they have the scale where it pays off to sell
data or do "big data" analysis. They are better for individual high-value
targets because they have more. to lose, and less to win, relative to whatever
they could expect by screwing you over. Protection against rogue employees is
also something that happens in larger teams, if at all.

~~~
throwGuardian
> Gitlab is still the team that ...

I just don't get why the internet neither forgets nor forgives. A startup in
it's early days makes mistakes, the only real mistake Gitlab made was be fully
transparent about theirs.

You vouch for CF (and no beef against them), but you know nothing of their
internal privacy or reliability pitfalls. That warm fuzzy feeling you have
about CF is a result of their carefully groomed PR coupled with 0% opacity on
internals. Again, not saying CF has any issues, but if they did, you wouldn't
know

~~~
ignoramous
> I just don't get why the internet neither forgets nor forgives.

Trust takes a lifetime to build and a moment to collapse.

~~~
tlb
Humans in their first few years of life are totally untrustworthy, yet most
adults can be trusted. That falsifies your theory of trust. Do you want modify
it to accommodate young people and/or young companies?

EDIT: toned down

~~~
falcor84
How does that falsify that theory of trust? I would take an extra set of pants
for a long trip with a 5 year old even if they hadn't pooped their pants for a
full year. It takes a long while before I let go of that preparedness.

~~~
StavrosK
The GP is saying that people (/companies?) change.

------
jakejarvis
via [https://gitlab.com/gitlab-com/gl-
infra/readiness/tree/master...](https://gitlab.com/gitlab-com/gl-
infra/readiness/tree/master/cloudflare#execution):

> 1\. Once traffic is ensured to flow though Cloudflare, we initiate
> decommission of Route53.

> We would disable the transfer lock and generate an auth code.

> _immediately after, we move the domain over to the Cloudflare registry_

I love the overall plan but this part would worry me... The most obvious
contingency plan when you're putting so many eggs into one basket is to keep a
kill-switch somewhere like your domain registrar, where you can abandon ship
entirely by switching nameservers in the worst of scenarios, right?

Correct me if I'm wrong but when the Cloudflare dashboard went down a few
weeks (months?) ago, no sort of DNS-level changes would have been possible.
(Either way, I don't think you can even set external nameservers for domains
on Cloudflare Registrar yet?)

Just curious about the thinking behind this particular move and why the pros
outweigh the cons of leaving the domain where it is.

------
mattbee
Oh - we're back to talking about trust & Cloudflare again.

Cloudflare have always hosted [ _] booter / stresser / DDoS-for-hire sites.
Right now I can find 8 sites on their network when I search for "booter" (it's
been higher). So Cloudflare are responsible for keeping criminal activity
online, and defending them from visibility to their downstream hosts, who
might otherwise cut them off.

Cloudflare also sell DDoS protection from the same criminals. Because they
host them, they can see where attacks will happen next - an advantage other
big CDNs won't tolerate.

That adds up to a protection racket - in the 90s this type of shady business
wouldn't have been able to source connectivity. But now they're the good guys
:( I don't get it.

[_] Cloudflare have tended to cry "we don't host anything!". But if they
stopped providing service, these sites probably couldn't exist. I call that
mission-critical hosting.

------
cagenut
wow you rarely see "tech" companies migrate in this direction (vs say
enterprise or smb).

------
secondo
_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._

Depending on your definition of ddos protection Fastly has those things along
with granular and semi scriptable configurability via vcl. Granted it’s been
2-3 years since I last did a comparison between Fastly and Cloudflare but I
can’t understand why a company with presumably a need for configurability at
the edge would make this choice. Cloudflare’s entry tiers are unbeatable in
price but beyond that it’s extremely bulky.

~~~
T4cC0re
One of the key reasons we decided to utilize Cloudflare as our vendor for WAF
and CDN was, that they uniquely offer to run SSH (or any TCP application,
really) and HTTP(s) on the same hostname.

~~~
secondo
You’re setting yourself up for some future and potentially hard to introspect
problems for yourself and your users with this setup. There are good reasons
to keep those endpoints separate. As an example, the anycast solution you’ll
rely on on that host, while great for short lived tcp sessions (https) will be
problematic for your long lived sessions (ssh) which will be disconnected
during routing changes in cloudflares network - ddos or operational changes.
That is unless you establish sub flows for those sessions using a unicast IP
address but now you’re accumulating additional complexity for the sake of
wanting it all on a single hostname.

~~~
T4cC0re
From a technical perspective, you are right. Anycast IPs are more fragile when
routing within an open session, as a route change might cause traffic to go to
a different PoP and thus break the connection.

The point of argument here was, however, the usability side. We offer our SSH
services on port 22 on gitlab.com and HTTP(s) on 80/443\. We do not want to
change this. Because if we did, we would need to tell everyone to use a
different URL to check out projects via SSH. And that is out of the question.

And to be honest, the complexity on our end is limited. And for the complexity
within Cloudflare to handle routing, etc., we pay them. We will also work with
them do debug any connectivity issues a client might have.

