CloudFlare旨在终结未加密的互联网。但是网络在转向HTTPS时遇到了一个鸡和蛋的问题。很久以前，建立一个支持HTTPS的网站是困难的、昂贵的和缓慢的。随后，CloudFlare的通用SSL等服务也随之出现，它使得从到https://的切换非常简单，只需点击一个按钮。只需单击一次，就可以通过HTTPS提供一个新创建的免费SSL证书。繁荣。突然之间，网站可以通过HTTPS访问，而且，更好的是，网站变得更快，因为它可以利用最新的web协议HTTP/2。不幸的是，故事并没有就此结束。许多其他安全网站都面临着内容混合的问题。混合的内容意味着绿色挂锁图标不会显示在https://网站上，因为事实上，它并不真正安全。问题是：如果一个https://网站包含了通过服务的站点（甚至是它自己的）的任何内容，那么绿色挂锁就无法显示。这是因为像图片、JavaScript、音频、视频等资源都是通过提供的，这为安全网站打开了一个安全漏洞。找麻烦的后门。Web浏览器早就知道这是个问题。早在1997年，InternetExplorer3.0.2用下面的对话框警告用户有混合内容的站点。今天，googlechrome在任何包含不安全内容的https://上都会显示一个带圆圈的i。Firefox显示了一个带有警告符号的挂锁。要想从这两个浏览器中的任何一个获得绿色挂锁，就需要通过HTTPS为每个单独的子资源（页面加载的资源）提供服务。如果你早在1997年就点击Yes，InternetExplorer就会忽略混合内容的危险，继续使用明文HTTP加载子资源。单击"否"将阻止加载它们（通常会导致一个损坏但安全的网页）。转换为完全安全的内容认为混合内容的解决方案很简单，这很诱人，但很天真："只需使用https://加载所有内容，然后修复您的网站"。不幸的是，从第一方和第三方网站加载到现代网站上的内容太多，这使得很难"简单地"做出这种改变。麦克·莫扎特的CC BY 2.0图像《连线》在一系列博客文章中记录了他们转换到https://。他们从4月份开始，花了5个月的时间在这个过程中（之前已经准备了几个月，只是为了在他们的主网站上访问https://。五月，他们写了一篇关于一个障碍的文章："[…]迁移到HTTPS的最大挑战之一是准备通过安全连接传送我们的所有内容。如果页面是通过HTTPS加载的，那么所有其他资产（如图像和Javascript文件）也必须通过HTTPS加载。我们看到大量关于这些"混合内容"问题的报告，或者在安全的HTTPS页面的上下文中加载不安全的HTTP资产的事件。为了做好我们的推广工作，我们需要确保我们提供的混合内容问题更少有线网的内容尽可能安全。"2014年，《纽约时报》将混合内容视为实现安全的主要障碍："要成功地迁移到HTTPS，所有对页面资产的请求都需要通过安全通道进行。这是一个令人生畏的挑战，而且有很多活动部件。我们必须考虑当前从不安全域加载的资源—从JavaScript到广告资产W3C认为这是一个巨大的问题，他说："最值得注意的是，混合内容检查可能会让负责将大量遗留内容移动到HTTPS上的管理员真正头疼。尤其是，浏览旧内容和手动重写资源URL是一项艰巨的任务。"并以英国广播公司（BBC）庞大的档案馆为例。但不只是媒体网站有混合内容的问题。许多CMS用户发现很难或不可能更新CMS生成的所有链接，因为它们可能隐藏在配置文件、源代码或数据库中。此外，需要处理用户生成内容的网站也面临的问题。混合内容的危险混合内容有两种类型：主动和被动。现代web浏览器处理这些不同类型混合内容的危险如下：主动混合内容（最危险的）被自动完全阻止，被动混合内容允许通过，但会导致警告。CC BY 2.0图片作者：Ben Tilley活动内容是任何可以修改DOM（网页本身）的内容。通过、、或标记包含的资源、使用url的CSS值以及使用XMLHTTPRequest请求的任何内容都可以修改页面、读取cookies和访问用户凭据。被动内容是其他任何东西：图像、音频、视频，它们被写入页面，但它们本身不能访问页面。活动内容是一个真正的威胁，因为如果攻击者成功地拦截了对的请求，他们可以用自己的内容替换该内容。这不是一个理论上的问题。2015年，Github被一个名为Great Cannon的系统攻击，该系统通过HTTP截获对普通JavaScript文件的请求，并将其替换为JavaScript攻击脚本。这个伟大的大炮通过拦截TCP并利用从加载的活动内容中固有的漏洞，将无辜用户的机器武器化。被动内容是另一种威胁：因为被动内容的请求是在透明的情况下发送的，所以窃听者可以监视请求并提取信息。例如，一个定位良好的窃听者可以监视cookies、访问的网页和潜在的身份验证信息。Firesheep Firefox插件可用于监视本地网络（例如，在咖啡店中）通过HTTP发送的请求，并自动窃取cookies，允许用户通过一次单击就劫持某人的身份。今天，现代浏览器阻止不安全加载的活动内容，但允许被动内容通过。然而，转换到所有https://是解决混合内容的所有安全问题的唯一方法。自动修复混合内容很长一段时间以来，我们一直希望帮助修复混合内容，因为我们的目标是使网络完全加密。而且，与其他CloudFlare服务一样，我们希望这是一种"一键式"体验。安东尼·伊斯顿的CC BY 2.0图像我们考虑了多种方法：自动插入升级不安全请求CSP指令upgrade unsecure requests指令可以添加到内容安全策略头中，如下所示：内容安全策略：升级不安全的请求它指示浏览器自动将任何HTTP请求升级为HTTPS。如果网站所有者知道每个子资源都可以通过HTTPS访问，那么这将非常有用。网站不需要将嵌入在网站中的改为https://，浏览器会自动处理。不幸的是，升级不安全的请求有很大的缺点。因为浏览器盲目地将每个URI升级到https://而不管最终的URI是否会实际工作页面被破坏。修改所有链接以使用https://由于并非所有CloudFlare网站的访问者使用的浏览器都支持不安全的升级请求，因此我们考虑在页面通过我们的服务时将所有升级为https://。由于我们能够实时解析和修改网页，所以我们可以创建一个不依赖浏览器支持的"升级不安全请求"服务。不幸的是，当被转换为https://时，仍然存在链接断开的问题，但实际上不能使用https加载资源修改指向其他CloudFlare站点的链接由于CloudFlare为我们的400万客户提供了免费的通用SSL，而且我们覆盖了很大一部分的web流量，因此我们考虑将我们知道（因为他们使用我们的服务）的URI将升级到https://即可。这在一定程度上解决了问题，但对于从HTTP升级到HTTPS这一普遍问题，并不是一个好的解决方案创建重写已知支持HTTPS的uri的系统最后，我们决定做一些聪明的事情：如果我们知道可以使用https为资源提供服务，那么将URI从升级到https://上。为了找出哪些链接是可升级的，我们求助于EFF优秀的HTTPS Everywhere扩展和googlechromehsts预加载列表，以增加我们对启用SSL的CloudFlare站点的了解。我们非常感谢EFF慷慨地接受帮助我们完成这个项目。HTTPS Everywhere规则集不仅仅是将切换为HTTPS://：它包含允许它（和我们）针对非常特定的uri的规则（和排除）。例如，下面是一个实际的HTTP Everywhere规则gstatic.com网站:它使用正则表达式来标识gstatic.com网站可以安全地升级到使用HTTPS。完整的规则可以在这里浏览。因为我们需要升级大量嵌入在网页中的uri（我们估计大约每秒500万个uri），所以我们对现有的HTML解析器（包括我们自己的）进行了基准测试，并决定为这种类型的重写任务编写一个新的。我们将在以后的文章中详细介绍它的设计、测试和性能。自动重写HTTPS现在，所有CloudFlare客户的客户仪表板中都提供了HTTPS自动重写功能。现在，此功能在默认情况下被禁用，并且可以在"一次单击"中启用：我们将监控此功能的性能和有效性，并在今年晚些时候为免费和专业客户启用该功能。我们还计划使用内容安全策略报告功能，为客户提供一个自动查看哪些uri仍有待升级，以便尽可能简单地转换到所有https://