25

Cloudflare offers 3 free SSL options: Flexible SSL, Full SSL, and Full Strict SSL.

The article “CloudFlare’s great new features and why I won’t use them” explores the shortcomings of the Flexible and Full (non-strict) SSL options.

The Full Strict SSL option encrypts clients’ connections to Cloudflare, and also Cloudflare’s connection to origin server — for which a Valid CA signed certificate is required. However, even with this option selected for your site, Cloudflare must be trusted, as they are the middleman, receiving the data, decrypting it and then encrypting it on its way to the origin server — and vice versa. Additionally, they must be trusted to actually require valid certificates from origin servers.

So, this setup allows Cloudflare to monitor, record, and modify any traffic between clients and the origin servers.

The fact that they can do this is a huge security concern, is it not? It cheapens the SSL system by appearing (to an average user) that your connection to the site you are visiting is secure cryptographically end-to-end, rather than the reality, whereby trust in Cloudflare is required.

How could Cloudflare offer SSL without requiring users to trust them?

TRiG
  • 609
  • 5
  • 14
Breakhty
  • 367
  • 1
  • 4
  • 13
  • 6
    I agree with your analysis. I've never used Cloudflare, but it sounds like their SSL services work by man-in-the-middle'ing your clients' connections. Do you control the end-site? Can you buy your own CA cert and set up your own SSL? – Mike Ounsworth Aug 27 '15 at 13:06
  • 1
    This isn't for a specific case. I'm just interested in the concept and ways that Cloudflare could offer a secure option that didn't require trust in them. – Breakhty Aug 27 '15 at 13:13
  • 1
    I think that they use packet inspection to implement part of their functionality (eg: DDoS protection](https://www.cloudflare.com/features-security)). So they sort-of need to see message contents or reduce their functionality. – Neil Smithline Aug 27 '15 at 13:53
  • 15
    The selling point of Cloudflare is that they do application layer traffic analysis. This necessarily requires them to decrypt the traffic. If you don't want them to decrypt traffic, then you have to do your traffic analysis in house and Cloudflare would be limited to TCP/IP filtering. This is insensible, because if you do traffic analysis in house, the attacker already won if it can overwhelm your traffic analyzer (this is essentially an IDS/Intrusion Detection System). Also, there are many better options to do TCP/IP filtering than Cloudflare. – Lie Ryan Aug 27 '15 at 15:04
  • TLS/SSL has never necessarily meant end to end encryption. For example, I can setup a reverse-proxy load balancer that forwards connections all over the world. The connection to the reverse-proxy load balancer might be over TLS, but the connections to the servers "behind" the reverse-proxy won't necessarily be. And those machines could be spread all over the world. – mikeazo Aug 27 '15 at 20:32
  • I think the scary part is that any CA could issue such a certificate for MITM, regardless of whether you use that CA or not. – kasperd Aug 28 '15 at 11:15

4 Answers4

27

From what I understand, no, Cloudflare couldn't work any other way.

Cloudflare analyses the connection before passing it to your webserver to ensure that it's correct and coming from a legitimate client. In order to do this, it needs to be able to see the contents of each packet from and to your server.

With SSL/TLS, each packet is encrypted and therefore not visible to Cloudflare. It needs to be able to decrypt any traffic before it can analyse it. To do that, it needs to have the private key for the cert used to encrypt the traffic.

The only way around this I see, is if Cloudflare sold its application that you could then self host. That still requires trusting the application (it may forward information to Cloudflare's servers, for instance), but at least it wouldn't be hosted elsewhere and totally out of your control. This would be a trade off, as you'd lose Cloudflare's distributed network. You would still have some benefits (anything implemented in software e.g. SQL injection protection), but would lose anything relying on the large network capacity (e.g. some DDoS protection).

Chris Murray
  • 1,275
  • 11
  • 17
  • 29
    +1 so in short, that would be like hiring a security guard for the front door of your building, but requiring them to wear a blindfold to "protect the privacy of the people coming in"? – Mike Ounsworth Aug 27 '15 at 14:14
  • 4
    A self-hosted cloudflare model would lose much of the advantages that come from cloudflare's great network infrastructure. – Neil Smithline Aug 27 '15 at 14:44
  • 1
    @NeilSmithline, indeed. I'll update the answer to emphasis the tradeoffs with a self hosted solution. – Chris Murray Aug 27 '15 at 14:47
  • 2
    A middlemen does not necessarily require the private key. This can be done by splitting the TLS handshake between the origin server and the middlemen, the middlemen ends up with the session key without needing the private key; this is similar to how an HSM can let the server decrypt TLS without disclosing the private key. Cloudflare calls this technology Keyless SSL, which lets you use Cloudflare without giving them your private key. – Lie Ryan Aug 27 '15 at 14:48
  • 2
    As @LieRyan notes, Keyless SSL is something that Cloudflare has developed (https://www.cloudflare.com/keyless-ssl) , which doesn't require them to have your private key, and also means that only your own certificate is required. Cloudflare states: _Note: Keyless SSL requires that CloudFlare decrypt, inspect and re-encrypt traffic for transmission back to a customer’s origin._ Would you like to update your answer with this in mind? I will then accept it. – Breakhty Aug 28 '15 at 03:09
  • @MikeOunsworth That is possibly the best analogy to describe the situation. Nice. – Chris Cirefice Aug 28 '15 at 14:38
10

It can't work any other way because the way cloudflare works is that they mirror your files for your users on their own servers. To request the files, clients connect to Cloudflare instead of your server. That means their browsers expect that the connection is encrypted with a valid TLS certificate from cdn.cloudflare.com, not from your website.

End-to-end encryption is not possible in this case because the HTTPS protocol does not support multiple nested encryption layers where each layer is signed by a different server. So Cloudflare must have access to the unencrypted files to serve them to your users.

Philipp
  • 48,867
  • 8
  • 127
  • 157
  • "multiple nested encryption layers where each layer is signed by a different server" -- for static content, for example, the original server could use its SSL certificate to sign the (hash of the) content with an expiry date, and the browser could take this into account when telling the user "where the content is from". But as you say this would need to be built into HTTPS and it isn't. Ofc cloudflare would still know what files you were looking at, that's far harder to work around given the goal of taking load off the original server. – Steve Jessop Aug 27 '15 at 15:06
  • HTTPS can be easily extended to support [encryption as a Content-Encoding](https://tools.ietf.org/html/draft-nottingham-http-encryption-encoding-00). The CDN could then cache the encrypted data, without necessarily knowing the content of the encrypted data themselves. This would require the client application to know how to decode the Content Encoding. – Lie Ryan Aug 27 '15 at 16:00
  • 3
    @LieRyan But how does the end-user get the decryption key for the cached content? Remember that the key must be transferred in a way that any anonymous web user can get it but cloudflare can not. – Philipp Aug 27 '15 at 16:03
9

The other answers are right that in practice Cloudflare can't provide their full services as effectively without introducing this kind of security risk.

Roughly speaking, Cloudflare does two things:

  1. They mirror your site, and can serve it from their own servers (their CDN). This way, if your site is getting hit with a DDoS, they can absorb the traffic and legitimate users will still be able to reach their services and see your site.

  2. They do application-level traffic analysis to detect attacks and malicious traffic. This requires inspecting the cleartext of the HTTP traffic.

Obviously, the second requires Cloudflare to be able to see your traffic.

The first also effectively requires Cloudflare to be able to pretend to be your site, so you have to trust them.

Now in principle Cloudflare might be able to achieve some of the benefits of mirroring your site, without requiring as much trust in them. In particular, one could imagine a scheme where your site's top-level pages are still served from your server, but where subresources such as images, CSS style sheets, IFRAMED subpages, dynamic data, and other information is served from Cloudflare's mirrors. Perhaps your site's top-level pages could be served with a very long time-to-live so it can be cached for a long time.

In this way, a user who has visited your site in the not-too-distant past may still have the top-level page cached, and then the rest of the content will be served from Cloudflare's servers. This allows the user to still see a lock icon and your site's address in the browser address bar, and Cloudflare won't need to your SSL private key.

However, this kind of scheme has major limitations and huge disadvantages. If your site is hit with a DDoS attack, users who have never been to your site before won't be able to visit it. Worse, you'll have to change all your pages so that the URL of every resource is modified to point to Cloudflare's network instead of your servers. This is a huge burden and would make it hard for site operators to adopt Cloudflare's protection. A big part of the appeal of Cloudflare is that it is easy to set up: you just change a line in your DNS configuration file and you're good to go. The kind of approach I mentioned loses all of those advantages.

In principle, you could imagine that the kind of scheme I outline might be useful for some limited class of websites that are AJAX-heavy, where they just have a single page that contains a bunch of Javascript that then loads all its resources through AJAX calls. However, that kind of website is relatively rare and is usually built by pretty tech-savvy developers who might not need services of a company like Cloudflare anyway -- they probably have their own ways to provide security and DDoS protection.

So, for all these reasons, the kind of alternative I outlined is probably not useful or attractive in practice.

D.W.
  • 98,420
  • 30
  • 267
  • 572
6

Potentially Cloudflare could work in a pass-thru SSL mode. However, it would not be as good at protecting against DDoS attacks.

In pass-thru mode, clients would make a TCP connection on port 443 to Cloudflare, which is forwarded to your web server. The SSL setup takes place between the client and your web server, so while the connection goes through Cloudflare, all they see is encrypted SSL traffic.

In that setup, Cloudflare could block traffic that is not for port 443, so they could protect you against DNS amplification attacks and the like. They could also do some basic protection, like blocking known botnet addresses. However, they would not be able to do any inspection of web traffic, which is something that Cloudflare does really well.

In practice you do need to trust your DDoS protector.

paj28
  • 32,736
  • 8
  • 92
  • 130