24 votes

Why is Cloudflare trusted with encryption?

I am a big fan of Cloudflare Tunnels, it's let me muck about with quite a few low risk apps and it's been fun.

one thing that's always bothered me though is the SSL setup.

According to their website, only enterprise users are allowed to manage their own TLS private keys.

I can kinda understand the logic behind free accounts not having that perk.

But if you are someone who really doesn't like cloudflare reading your traffic or you are a business, it seems odd to me that it's not being demanded of cloudflare that they make it more available for paid users to not expose their TLS private keys to cloudflare.

Why are so many folks OK with cloudflare essentially being able to read all their traffic?

or am I overestimating how many people are using the Pro and Business account? is the majority of their users just Free or Enterprise?

16 comments

  1. whs
    (edited )
    Link
    Cloudflare is still getting to see the traffic with Keyless SSL. If you see the diagram in their blog, with keyless SSL you don't have to trust Cloudflare with the private key, Cloudflare will ask...
    • Exemplary

    Cloudflare is still getting to see the traffic with Keyless SSL. If you see the diagram in their blog, with keyless SSL you don't have to trust Cloudflare with the private key, Cloudflare will ask you to perform things with your private key instead. At the very end, a session key is established which is the actual key that perform most of the encryption. This session key is known to Cloudflare and the visitor, but not to you. I don't think it is a useful product as it only slow down websites without any meaningful security benefits. Perhaps it is useful in selling enterprise plan to people who don't understand perfect forward secrecy.

    It is critical that Cloudflare must see the traffic to perform what they claims to do: WAF, DDoS prevention, Security (Cloudflare Access) and CDN. If you don't trust a 3rd party to let them see the plain text traffic, you can't outsource those three tasks.

    How Tailscale solve this problem with their Funnel product is interesting. Basically, client talk to a Tailscale server who only see plain text traffic. However, even with HTTPS the actual hostname to connect to is not encrypted. Tailscale server then can know where to route the traffic to, and connect pipe from one end to the other without doing any other magic. People often think this is the same as Cloudflare Access, but with Access you get SSO login while this is basically the same as exposing your local server to the internet without protection (perhaps except for port restricted firewall, and a basic L4 DDoS prevention since it goes to Tailscale's proxy). I wonder how would this product work after ECH starts to encrypt the actual hostname.


    Edit: Let's talk about more why these four products needs to see plain text traffic, and why do people need to use them.

    First, WAF. I used to think WAF is bullshit - you don't "add" security by putting another flaky layer in front. After Log4j I realize the value of this product. WAF scan the actual body of all requests, and if it matches a signature it blocks it. The value of outsourcing this to Cloudflare is that they can update the WAF signature faster than you could. Take Log4shell, for example, I think it was released on a Friday. If you need to rebuild your source with updated Log4j, test that the new update works properly and deploy to a fleet of server that would take a few hours at best. Multiply that by numbers of services your enterprise have, and you could see why you can't possibly update them all in time. WAF is not perfect, but it buy time that Cloudflare could probably start rolling out the Log4shell signature even before you see the news. Note that Cloudflare's WAF is very limited in free plans, as you could imagine scanning payloads at their scale is expensive.

    Second is DDoS prevention. Arguably, you could do DDoS prevention at Layer 4 without seeing the encrypted traffic, but you can't serve that Cloudflare captcha page at L4 so you'll need to either let more bad traffic through, or risk more false positive. It's like judging good and bad person just from their silhouette. Many anti-DDoS providers would say you can't handle DDoS without them, it's like if you have small pipe and large stream of data come through. You can't possibly get them all through to sieve through it - you need someone who actually have large pipes. In reality I think most DDoS are small enough that you could handle yourself if you're prepared, and large DDoS that you can't handle are rare. It's like buying insurance - and their pricing reflect that - you don't get charged for DDoS attacks.

    Third, Access. There's a few modes available in Cloudflare Access, including actual VPN. If you use VPN, you don't need to allow Cloudflare to see the plain text traffic. But you'd need to install their VPN client. If you just want to access with unmodified web browser, they need to intercept the authentication cookie in-line.

    Lastly, CDN. In CDN if it is a cache hit the traffic doesn't even go to your origin - Cloudflare is the source of the data. This also applies to their Development Platform products, like Workers or Stream. I don't think you could economically run your own global CDN as it requires economy of scale - Cloudflare's servers are located in hundreds of cities around the world and possibly in every major ISP's datacenters in many countries. I've heard from a local player that they can't just call the local telco to colocate their CDN node as it is not a space for general rack-for-rent. CDN is quite cheap enough that I think it'd be easier to buy than to build your own, and Cloudflare is in the "premium" space here as they bundle the security products with it (AWS Cloudfront, for example, has DDoS prevention as a separate product and do charge you for DDoS traffic).

    21 votes
  2. delphi
    Link
    Seems to me the simplest answer is that most people don't care. It's a low volume product compared to Domains and SSL, which is their big money maker. I mean, you said it yourself. You use tunnels...

    Seems to me the simplest answer is that most people don't care. It's a low volume product compared to Domains and SSL, which is their big money maker.

    I mean, you said it yourself. You use tunnels to "much about" with "low risk apps". I suspect someone who's looking for a modern and proven solution for a use case like this that's load bearing and mission critical would probably go to Tailscale first. If you just need to test something, you probably don't even want the option to manage your keys. Just set it and forget it, have it work as quickly as possible.

    If you need more than that, chances are you're a business that needs it to operate. And then, they can charge you.

    12 votes
  3. [3]
    Weldawadyathink
    Link
    I think there are two different questions here. Every answer in this thread answers one of the questions but not the other. I will try to integrate them together. Questions: Why do companies trust...

    I think there are two different questions here. Every answer in this thread answers one of the questions but not the other. I will try to integrate them together.

    Questions:

    • Why do companies trust cloudflare with encryption?
    • Why do hobbyists trust cloudflare with encryption (and often recommend cloudflare tunnels specifically)?

    The companies' trust is pretty simple to answer. They need a CDN. In order to do anything useful, a CDN has to terminate the ssl connection. So you have to trust them with encryption (even if you have enterprise and control the key, they have to handle the unencrypted data at some point). If you are a company you almost certainly need a CDN. Your options are either build server infrastructure around the world close to your users (basically build your own CDN) or use a third party CDN which will have to handle the encryption. So for most companies, the question isn't if they should trust a company with encryption, its which company should they trust with encryption. And Cloudflare is really good at being a CDN. Their other products are also quite impressive, but they wouldn't matter at all if Cloudflare didn't already have really good CDN infrastructure.

    The hobbyist answer is a bit more complicated. Cloudflare uses the Microsoft Office/Photoshop business model. Make sure your software is the only option in schools, and when people enter the workforce, they request that their employer buy your software. To be more precise, Cloudflare targets hobby projects with an extremely generous free tier. Seriously, just compare Cloudflare's pricing to any other CDN. All of them have worse free tiers than Cloudflare. Unlike Microsoft and Adobe, Cloudflare's product is often better than the competition, and they have burned fewer bridges than Microsoft and Adobe, so Cloudflare doesn't have a bad reputation. They also do many things that are genuinely good for hobbyist consumers. For example, their domain registrar is at-cost, so they don't make a dime and you get lower prices. Cloudflare tunnels are another example. I am sure that there are many corporate users, but I don't think it's necessarily a profitable product alone. The real benefit is all the reddit threads where someone asks about setting up a VPN and the answer is "just use Cloudflare Tunnels". The combo of being genuinely good for hobby developers and having a genuinely good product is such a great way to become popular and liked.

    And should you trust them to handle encryption for you? From a practical standpoint, there isn't much reason not to. That free tier is very compelling. My website, audiobookcovers.com, would be significantly cheaper to run on Cloudflare workers, and would probably be faster. Will they sell you data? If you have a corporate contract with them, no. If you are on the free tier, probably not. So why would people not choose Cloudflare? Well some people are worried about the nebulous problems of one company having too much control over the internet. I don't want to dismiss these concerns, but Cloudflare has yet to do anything to really cause issues with their current control. Personally, I don't use them because I don't like their pushy sales tactics. I am not even the target for their sales tactics, but I don't like how they handled those issues. Despite that, I still read the Cloudflare blogs (they are genuinely really good) and use 1.1.1.1 as my DNS resolver.

    6 votes
    1. [2]
      b3_k1nd_rw1nd
      Link Parent
      The implication being that if they are going to serve cached content on your behalf, it needs to be delivered in the encrypted format that the browser is expecting given it's an HTTPS connection...

      In order to do anything useful, a CDN has to terminate the ssl connection.

      The implication being that if they are going to serve cached content on your behalf, it needs to be delivered in the encrypted format that the browser is expecting given it's an HTTPS connection which means cloudflare needs to encrypt it before sending it on behalf of your reverse proxy?

      And because the cloudflare tunnel feature is utilizing the already existing CDN network, it's a lot less hassle for them (and the developer) to just rely on cloudflare to do what it does best and serve content it itself encrypts?

      1. Weldawadyathink
        Link Parent
        Pretty much, yep. If you serve someencryptedfile.css to a customer, a CDN could in theory cache that. But TLS uses a different encryption key for every connection, so they could only serve that...

        Pretty much, yep. If you serve someencryptedfile.css to a customer, a CDN could in theory cache that. But TLS uses a different encryption key for every connection, so they could only serve that file to that exact user during that exact same session. The entire point of a CDN is that they serve your customer files so your servers don’t have to. In order to serve files to your customers, they have to « pretend » to be you and encrypt the files with your private key (or use insecure http). And they also have to be able to decrypt your responses to the customer. So they decrypt someencryptedfile.css into styles.css, store a copy, and can send it to other customers who request that file.

        There are some other setups that you could do. You can serve your assets like images and favicons from a different domain like cdn.mywebsite.com. The CDN still needs to handle encryption, but it can only decrypt the static assets you put on that subdomain. However that does mean you don’t get the CDN advantages on the main html/css files served for your website. But that is a trade off you can make.

        And yeah, the Cloudflare tunnels product absolutely uses other Cloudflare technology. I don’t know what parts of the Cloudflare tech stack it uses, because I am not familiar with how it works. Cloudflare uses dogfooding extensively throughout all their products. If you haven’t heard that term before, it just means they use their own products internally. If their products have reliability issues or bugs, Cloudflare has probably already found them and fixed them, because they have been using that product internally. Cloudflare workers is a great example of this. Cloudflare needed a way to write bits of JavaScript that ran on their edge servers. They were not planning on selling it, they just needed it to make their service better. But it turns out they made a really good product, and lots of companies could use it. Now when they release it, it is already reliable. Compare this to something like google cloud. (I have heard this from people, but I am not sure that it’s true). Google cloud doesn’t dogfood its own products. Google has a product called Spanner, which is supposed to be a SQL database for very large datasets. But Google doesn’t use it internally, and it’s apparently quite buggy. What is worse, Google has an internal database called spanner that is entirely unrelated to the spanner that they sell. Their internal spanner is very reliable and scalable, because it has to be to run things like search, Adsense, analytics, YouTube, etc. This dogfooding is why Cloudflare products are so good. A CDN that handles as much traffic as Cloudflare is probably the single most difficult scale problem in computer science. So if a product is good enough for a Cloudflare scale CDN, it is absolutely good enough for your company/hobby project with tiny traffic loads. And every other company in the world (excluding AWS/Azure or other CDNs) has tiny traffic when compared to the traffic Cloudflare handles.

        1 vote
  4. [2]
    skybrian
    (edited )
    Link
    @whs explained it but I’ll try explaining a little differently: Cloudflare needs to see all the requests coming in to a customer’s website, even for Enterprise where there’s a system for...

    @whs explained it but I’ll try explaining a little differently:

    Cloudflare needs to see all the requests coming in to a customer’s website, even for Enterprise where there’s a system for protecting the private key itself.

    What do enterprises get from not giving Cloudflare their private key? It guards against some worst-case scenarios. Cloudflare can’t leak the private key if they don’t have it.

    But it’s more expensive to run their servers that way. The customer has to run one or more key servers with the capacity to serve lots of key server traffic even during some denial-of-service attacks (if they force a new handshake each time), or their website will be unavailable.

    Keyless SSL supports multiple key servers for the same certificate. Key servers are stateless, allowing customers to use off-the-shelf hardware and scale the deployment of key servers linearly with traffic. By running multiple key servers and load balancing via DNS, the customer’s site can be kept highly available.

    Since you still have to trust Cloudflare with your web traffic, it’s not an obvious win. It’s a subtle tradeoff that’s not always worth it. So it makes some sense for Cloudflare to only offer this more complex setup to their biggest customers.

    3 votes
    1. vord
      Link Parent
      Yea moral of the story is you need to trust your load balancer. Especially if you want it to offload SSL.

      Yea moral of the story is you need to trust your load balancer. Especially if you want it to offload SSL.

      3 votes
  5. d32
    Link
    I hate that. Cloudflare is a big Man-in-the-middle actor that reads all your traffic and discloses it to who knows who. It is not to be trusted. It has too much power to not be corrupted already...

    I hate that. Cloudflare is a big Man-in-the-middle actor that reads all your traffic and discloses it to who knows who. It is not to be trusted. It has too much power to not be corrupted already or by design.

    1 vote
  6. [8]
    fxgn
    Link
    SSL is inherently about trust. Certificate are issued by Certificate Authorities, and while, unlike Cloudflare, they don't directly handle your traffic, any of them is able to decrypt it if they...

    SSL is inherently about trust. Certificate are issued by Certificate Authorities, and while, unlike Cloudflare, they don't directly handle your traffic, any of them is able to decrypt it if they somehow intercept it (in fact, this has happened, as mentioned in the thread I linked). And people already trust Cloudflare with a lot of stuff. So I guess they just trust it with this as well, or they don't care.

    1 vote
    1. [5]
      vord
      (edited )
      Link Parent
      From your link: This is an important distinctinction. CAs are not able to decrypt your traffic. However, a trusted CA can be used to perform man-in-the-middle attacks if it handles the traffic....

      From your link:

      Note that technically, it's not the rogue CA that decrypts the traffic. It provides the means for interception by other networks actors to remain undetected by the browsers.

      This is an important distinctinction. CAs are not able to decrypt your traffic. However, a trusted CA can be used to perform man-in-the-middle attacks if it handles the traffic.

      The attacker intercepts all client traffic, specifically feeding it a bad server cert. Client thinks they're using their bank's cert, but it's using the attacker's. The attacker then proxies all of the client's requests, decrypting from client, then re-encrypts with real cert to forward to website, repeat in reverse.

      It's why you should always assume a work computer is reading all of your traffic.

      6 votes
      1. [4]
        b3_k1nd_rw1nd
        Link Parent
        How is that a MITM attack? My understanding of MITM is both the sender and receiver are legitimate participants in a conversation, they just don't know their communication is being read. but what...

        However, a trusted CA can be used to perform man-in-the-middle attacks if it handles the traffic.

        The attacker intercepts all client traffic, specifically feeding it a bad server cert. Client thinks they're using their bank's cert, but it's using the attacker's. The attacker then proxies all of the client's requests, decrypting from client, then re-encrypts with real cert to forward to website, repeat in reverse.

        How is that a MITM attack? My understanding of MITM is both the sender and receiver are legitimate participants in a conversation, they just don't know their communication is being read.

        but what you are describing is a malicious website (which I guess in this example is the receiver) that the user interacts, not knowing its malicious.

        1 vote
        1. [3]
          whs
          Link Parent
          It is possible if you're both the CA and the ISP.

          It is possible if you're both the CA and the ISP.

          2 votes
          1. [2]
            b3_k1nd_rw1nd
            Link Parent
            so these seem to be the relevant snippets describing the technical harms From...

            so these seem to be the relevant snippets describing the technical harms
            From https://web.archive.org/web/20151205093315/https://digital.report/experts-concerned-kazakhstan-plans-to-monitor-users-encrypted-traffic/

            Committee for Communications, Informatization, and Information at the Ministry of Investment and Development, [...] would be introducing the national security certificate as of 1 January 2016.
            the users must install the national certificate on all devices used to access the internet, including mobile ones. The national operator will publish step-by-step installation instructions on its website by the end of 2015 (see the cached Google page of the Kazakhtelecom press release).

            It seems that the certificate will be used not only for HTTPS connections but also for other TLS encrypted connections, including FTPS, IMAP and SMTP with TLS”, states habrahabr.ru. Technically speaking, the new certificate, when installed by a user, would replace the security certificates already installed on websites, with the national certificate ‘acting’ as an intermediary between a user and a site. This is precisely what encryption technologies were intended to eliminate.

            the intelligence services could conduct unlimited MITM attacks and decode any encrypted data. Securitylab analysts believe that the initiative is intended to **intercept all SSL traffic in the region. **

            From https://www.theregister.com/2015/12/03/kazakhstan_to_maninthemiddle_all_internet_traffic/

            This spying will be made possible by insisting everyone installs a "national security certificate" on their computers and mobile gadgets – most likely a root CA certificate just like the ones found in Lenovo's Superfish and Dell's Superfish 2.0 scandals.

            This cert will trick web browsers and other apps into trusting the telco's systems that masquerade as legit websites, such as Google.com or Facebook.com. Rather than connect directly to those sites, browsers will really be talking to malicious man-in-the-middle servers.

            The implication being that they can intercept all the SSL traffic in a region by taking control of the ISP data-links and thanks to the bad server cert, they can pretend to be a website they are not.

            However, MITM would necessarily mean they are also forwarding those requests to the legitimate site no? Cause otherwise, technically speaking, they're not "in the middle", they're actually doing the responding themselves too.

            1 vote
            1. vord
              Link Parent
              The idea is that they would be spying on the contents without the users knowledge. To the user and the website, this would be almost completely transparent unless they knew about the compromised CA.

              The idea is that they would be spying on the contents without the users knowledge. To the user and the website, this would be almost completely transparent unless they knew about the compromised CA.

    2. [2]
      papasquat
      Link Parent
      Yep, the entire global PKI system depends on trusting CAs. The system doesn't work unless you trust someone. Trusting cloud flare isn't much different from trusting entrust, or globalsign, or...

      Yep, the entire global PKI system depends on trusting CAs. The system doesn't work unless you trust someone. Trusting cloud flare isn't much different from trusting entrust, or globalsign, or letsencrypt. The modern, encrypted web wouldn't be feasible without CAs that we place a high level of trust in.

      2 votes