Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Alternative to Cloudflare - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Alternative to Cloudflare

2»

Comments

  • bikegremlinbikegremlin Member
    edited April 2022

    @stevewatson301 said:

    @bikegremlin said:

    @Erisa said:

    @bikegremlin said:

    @Erisa said:

    @be9hop said:
    Cloudflare is secure as long as you switch the SSL type from Flexible to Full (Strict). You must install their origin cert on your server but that negates most these negative comments. Some people haven't figured that out yet.

    Hi, I want to preface this message by saying that I'm an extremely heavy Cloudflare user, but I respect other people's varying views on the subject.

    Changing the SSL to Full (Strict) is always a good idea because it prevents parties other than you and Cloudflare from seeing the traffic. This is great and I think is why you sent that message.

    However when I look through the link the OP gave, their concern was more that Cloudflare has access to the data to begin with, which they still will if the SSL is set to Full (Strict).

    For any proxied record, SSL termination will happen at Cloudflare, which makes sense to anyone who understands how a CDN is supposed to work, but some people dislike this for various privacy and security concerns related to having to trust Cloudflare with their production traffic.

    Just to add:
    Even the "Full" setting (so not "Full-strict") will make the traffic be encrypted.
    The difference is that the Full setting will make Cloudflare happy with using your self-signed certificate, instead of a certificate issued by a trusted CA.

    Now, we can debate for days whether any CA is to be trusted and whether a self-signed cert, especially if renewed regularly, is more, or less secure. But that's a different topic IMO.

    As has been noted above, the issue here is precisely the fact that the certificate is self-signed. For sure it is better than leaving your traffic bare and naked to the web, but an ISP can still theoertically MITM your connection by replacing it with their own self-signed cert and not only will Cloudflare be fine with that, it also won't tell you.

    The Origin Certs that Cloudflare provides for you are the answer if you potentially don't trust the CAs, since the origin cert is trusted by Cloudflare and Cloudflare is who you are trusting with all your traffic in this scenario.

    SSL/TLS does not work without proper certificate trust. A self-signed certificate is never secure unless the other end has been specifically told to trust your personal CA and no others.

    One thing is not clear:
    In the settings, I tell Cloudflare which IP to look for.
    Wouldn't such MITM attack require the attacker to fake the IP as well, and would that be possible (especially if they don't know which IP that is)?

    Given the right set of conditions, a malicious ISP can publish a BGP announcement such that the traffic for a certain prefix is routed through them instead, and then present the certs by at the time the IP datagrams of interest are routed via said malicious ISP. Search for "BGP hijacking".

    Figuring out your origin isn't that difficult either; if you have a website that sends email over SMTP, the "Received" header may expose your origin IP. Or you could look for the website's headers, titles etc. on Shodan/Censys, or look up historical DNS records through Securitytrails (or similar security products).

    Thanks @stevewatson301 and @Erisa for the follow-up explanation.

    Another question, regarding SMTP:
    If I use a separate email service (like MXroute), email headers might only reveal their server's IP?

    To clarify - I don't think using self-signed certs is as secure. If nothing else, any problems with CA certs verification and/or renewal lets me know there could be another problem with my setup. Just, I can imagine scenarios where revealing the hosting server IP could still be a bad idea, regardless of the above-explained MITM scenario.

    Thanked by 1Erisa
  • @bikegremlin said: If I use a separate email service (like MXroute), email headers might only reveal their server's IP?

    AFAIK MXRoute does not reveal the origin IP this way, however IMO your origin should firewall off non-Cloudflare IPs for the HTTPS port.

    @bikegremlin said: don't think using self-signed certs is as secure. If nothing else, any problems with CA certs verification and/or renewal lets me know there could be another problem with my setup.

    IMO that's a solved problem though. You can use caddy with the dns.cloudflare plugin enabled, and provide your Cloudflare API key to caddy so that it can fetch and renew certs at the right cadence.

    If you are using nginx or apache, you can also use certbot with the DNS-01 challenge like I mentioned above, but there are too many moving components in that setup and honestly it's just that much easier to migrate from nginx/apache to caddy.

    Thanked by 1bikegremlin
  • @stevewatson301 said:

    @bikegremlin said: If I use a separate email service (like MXroute), email headers might only reveal their server's IP?

    AFAIK MXRoute does not reveal the origin IP this way, however IMO your origin should firewall off non-Cloudflare IPs for the HTTPS port.

    @bikegremlin said: don't think using self-signed certs is as secure. If nothing else, any problems with CA certs verification and/or renewal lets me know there could be another problem with my setup.

    IMO that's a solved problem though. You can use caddy with the dns.cloudflare plugin enabled, and provide your Cloudflare API key to caddy so that it can fetch and renew certs at the right cadence.

    If you are using nginx or apache, you can also use certbot with the DNS-01 challenge like I mentioned above, but there are too many moving components in that setup and honestly it's just that much easier to migrate from nginx/apache to caddy.

    All clear - thank you very much.

    :)

  • ehhthingehhthing Member
    edited April 2022

    I mean if your objection is only to cloudflare...

    DNS: Google Domains DNS (anycast with Google's network) or DigitalOcean DNS.

    CDN: CloudFront (first 1TB is free, very expensive afterward though)

    Incoming mail: Selfhosted or ImprovMX

    Not sure why you're picking on a single company though...

  • jbilohjbiloh Administrator, Veteran

    Having had the distinct joy of defending this site from attacks for the last few years I've got to say that Cloudflare's application layer protections and tools are excellent and have gotten noticeably better the past year.

    Thanked by 4Erisa SinV eva2000 JasonM
  • eva2000eva2000 Veteran
    edited April 2022

    It's quite clear from this discussions in this thread, not everyone understands how Cloudflare operates and what you can do to safeguard your connections. But ultimately, it does come down to if you trust Cloudflare or not.

    With Cloudflare, you can use Advanced Certificate Manager (ACM) to setup your own Custom Origin Trust Store with your own created CA cert and signed origin SSL certs https://developers.cloudflare.com/ssl/origin-configuration/custom-origin-trust-store/

    By default, Cloudflare’s edge network maintains a list of publicly trusted certificate authorities. This means that when using Full (strict) encryption mode , Cloudflare will only trust origin server certificates issued by a CA in this trust store.

    Custom Origin Trust Store allows you to upload certificate authorities (CAs) that Cloudflare will use to authenticate connections to your origin server. Use this feature to override the default trust store with your preferred CA or CAs.
    When a CA has been uploaded to Custom Origin Server Trust Store, Cloudflare will ignore all default publicly trusted CAs and exclusively use the CA or CAs that have been uploaded to authenticate the origin server.

    from inline help for Custom Origin Trust Store dashboard

    Custom Origin Trust Store
    What is an origin server trust store?
    By default, our edge maintains a set of common public certificate authorities as well as our own Origin CA which are considered trusted. This means that when using Full(strict) encryption mode, Cloudflare will only trust origin server certificates issued by a CA in this trust store.

    Why use custom origin server trust store?
    If you prefer to use a privately trusted certificate authority or want to limit trust to specific public CAs, you may upload one or more CAs that you desire Cloudflare to deem as trusted when connecting to your origin server.

    What happens to the default trust store when I upload my private CA?
    When a CA has been uploaded to Custom Origin Server Trust Store, Cloudflare will ignore all default publicly trusted CAs and exclusively use the CA or CAs that have been uploaded to authenticate the origin server.

    What happens when my uploaded CA expires?
    If no alternative CAs are valid within the trust store, Cloudflare will not be able to properly authenticate connections to the origin server with Full(strict) encryption mode enabled.

    And if you don't want to pay $10/month for Advance Certificate Management (ACM), you can also use Authenticated Origin Pulls but instead of using CF CA provided Origin Pull client TLS certificate, you can setup your own custom CA signed client TLS certs and upload those to Cloudflare via API for custom client TLS authenticated original pull certificate setups https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/set-up/#per-hostname--customer-certificates

    When enabling Authenticated Origin Pull per hostname, all proxied traffic to the specified hostname is authenticated at the origin web server. Customers can use client certificates from their Private PKI to authenticate connections from Cloudflare.

    In either above cases, if you setup your own CA and signed client/server TLS certs and authentication to your origin, only legit connections to your origin server would be allowed. Though you'd be responsible for safeguarding your own CA private key etc.

  • jsgjsg Member, Resident Benchmarker

    @rm_ said:
    CDNs are overrated. Get a VPS/dedi from a DDoS-protected provider, and self-host the rest.

    How dare you say that?!!! Those dog and car pics and my-sisters-coiffeur sites must be globally reachable within max 30 ms (in part because they are made creepily bad and are bloated too)!!!

  • ChuckChuck Member

    I think most people choose to stay with cloudflare because they're on the Free plan.
    Other companies don't offer the Free plan.

  • There are a few Cloudfare equivalents on the market. You may verify the evaluations and dependability before attempting to use them. Here are your options.

    • Fastly Deliver
    • Akamai CDN
    • CloudFront CDN
    • Google Cloud CDN
    • Microsoft Azure CDN
    • Tata Communications CDN
    • StackPath CDN
    • Medianova CDN
  • If you self host. Time to live and max connections per ip were some of the settings I had to mess with in litespeed. Cloudflare does offer SSL that makes your site looks more sexy and secure. And I would configure iptables for a good firewall. Change the port number to your ssh and any other outbound port connections to something higher than 1000. The firewall should drop all ping request and other packets only responding to that port 80 443 etc.

  • My site is hosted on a Litespeed server so moved away from Cloudflare and using Quic.cloud CDN. However, I use Cloudflare for DNS hosting.

  • @rm_ said:
    CDNs are overrated. Get a VPS/dedi from a DDoS-protected provider, and self-host the rest.

    Its rare to get the latency or bandwidth anywhere. Amazon, Cloudflare and a handful others have multiple 400G ports everywhere. Do you need it? If you dont let your website load hundreds of assets no one cares about 100ms vs 100x1ms on cloudflare.

    Everyone hugging the same trees is a terrible mistake that only leads to trouble in the end. It doesnt take much effort to configure some (lowend) option, safe some money on the way and help decentralize

    Some providers here even offer fancy things like Anycast

Sign In or Register to comment.