Cloudflare 提供 3 个免费的 SSL 选项：灵活 SSL、完全 SSL 和完全严格 SSL。
文章“ CloudFlare 的出色新功能以及我为什么不使用它们”探讨了灵活和完整（非严格）SSL 选项的缺点。
Full Strict SSL 选项可加密客户端与 Cloudflare 的连接，以及 Cloudflare 与原始服务器的连接——这需要有效的 CA 签名证书。但是，即使为您的站点选择了此选项，Cloudflare 也必须受到信任，因为它们是中间人，接收数据、解密数据，然后在传输到源服务器的过程中对其进行加密——反之亦然。此外，必须信任它们才能实际需要来自原始服务器的有效证书。
因此，此设置允许 Cloudflare 监控、记录和修改客户端与源服务器之间的任何流量。
他们可以做到这一点是一个巨大的安全问题，不是吗？它通过显示（对普通用户而言）您与您正在访问的站点的连接是端到端加密安全的，而不是现实，从而降低了 SSL 系统的成本，因此需要对 Cloudflare 的信任。
Cloudflare 如何在不要求用户信任的情况下提供 SSL？
据我了解，不，Cloudflare 无法以任何其他方式工作。
Cloudflare 在将连接传递到您的网络服务器之前对其进行分析，以确保它是正确的并且来自合法客户端。为了做到这一点，它需要能够查看来自和发往服务器的每个数据包的内容。
使用 SSL/TLS，每个数据包都经过加密，因此对 Cloudflare 不可见。它需要能够解密任何流量，然后才能对其进行分析。为此，它需要拥有用于加密流量的证书的私钥。
我看到的唯一解决方法是，如果 Cloudflare 出售了您可以自行托管的应用程序。这仍然需要信任应用程序（例如，它可能会将信息转发到 Cloudflare 的服务器），但至少它不会托管在其他地方并且完全不受您的控制。这将是一个权衡，因为您将失去 Cloudflare 的分布式网络。您仍然可以获得一些好处（在软件中实现的任何东西，例如 SQL 注入保护），但是会失去任何依赖于大网络容量的东西（例如一些 DDoS 保护）。
它不能以任何其他方式工作，因为 cloudflare 的工作方式是它们在自己的服务器上为您的用户镜像您的文件。要请求文件，客户端会连接到 Cloudflare 而不是您的服务器。这意味着他们的浏览器期望连接使用来自 的有效 TLS 证书进行加密cdn.cloudflare.com，而不是来自您的网站。
在这种情况下，端到端加密是不可能的，因为 HTTPS 协议不支持多个嵌套加密层，其中每一层都由不同的服务器签名。因此，Cloudflare 必须有权访问未加密的文件才能将它们提供给您的用户。
其他答案是正确的，实际上 Cloudflare 无法在不引入此类安全风险的情况下有效地提供其完整服务。
粗略地说，Cloudflare 做了两件事：
他们镜像您的网站，并且可以从他们自己的服务器（他们的 CDN）提供服务。这样，如果您的网站受到 DDoS 攻击，他们可以吸收流量，合法用户仍然可以访问他们的服务并查看您的网站。
他们进行应用程序级流量分析以检测攻击和恶意流量。这需要检查 HTTP 流量的明文。
显然，第二个要求 Cloudflare 能够看到您的流量。
第一个还需要 Cloudflare 能够伪装成您的站点，因此您必须信任它们。
现在，原则上 Cloudflare 可能能够实现镜像站点的一些好处，而不需要对它们有太多的信任。特别是，可以想象这样一种方案，您的站点的顶级页面仍由您的服务器提供，但图像、CSS 样式表、IFRAMED 子页面、动态数据和其他信息等子资源则由 Cloudflare 的镜像提供。也许您网站的顶级页面可以提供很长的生存时间，因此可以缓存很长时间。
这样，在不远的过去访问过您网站的用户可能仍会缓存顶级页面，然后其余内容将从 Cloudflare 的服务器提供。这使用户仍然可以在浏览器地址栏中看到锁定图标和您的站点地址，并且 Cloudflare 不需要您的 SSL 私钥。
然而，这种方案有很大的局限性和巨大的缺点。如果您的网站遭到 DDoS 攻击，以前从未访问过您的网站的用户将无法访问它。更糟糕的是，您必须更改所有页面，以便修改每个资源的 URL 以指向 Cloudflare 的网络而不是您的服务器。这是一个巨大的负担，并且会使站点运营商难以采用 Cloudflare 的保护。Cloudflare 的一大吸引力在于它易于设置：您只需在 DNS 配置文件中更改一行，就可以开始使用。我提到的那种方法失去了所有这些优势。
原则上，您可以想象我概述的那种方案可能对某些有限类别的 AJAX 重度网站有用，它们只有一个页面，其中包含一堆 Javascript，然后通过 AJAX 调用加载其所有资源. 但是，这种网站相对较少，通常由精通技术的开发人员构建，他们可能无论如何都不需要像 Cloudflare 这样的公司的服务——他们可能有自己的方式来提供安全和 DDoS 保护。
因此，出于所有这些原因，我概述的那种替代方案在实践中可能没有用或没有吸引力。
Cloudflare 可能会在直通 SSL 模式下工作。但是，它在防御 DDoS 攻击方面并没有那么好。
在直通模式下，客户端将在端口 443 上与 Cloudflare 建立 TCP 连接，该连接将转发到您的 Web 服务器。SSL 设置发生在客户端和您的 Web 服务器之间，因此当连接通过 Cloudflare 时，他们看到的只是加密的 SSL 流量。
在该设置中，Cloudflare 可以阻止不用于端口 443 的流量，因此它们可以保护您免受 DNS 放大攻击等。他们还可以做一些基本的保护，比如阻止已知的僵尸网络地址。但是，他们无法对 Web 流量进行任何检查，而 Cloudflare 在这方面做得非常好。
在实践中，您确实需要信任您的 DDoS 保护程序。