【问题标题】：CloudFlare SSL compatibility with ASP.NET MVC RequireHttpsCloudFlare SSL 与 ASP.NET MVC RequireHttps 的兼容性
【发布时间】：2013-04-03 18:59:29
【问题描述】：
我在 AppHarbor（它使用 Amazon EC2）上托管一个 ASP.NET MVC 4 站点，并且我正在使用 CloudFlare 来实现灵活 SSL。我在尝试使用 RequireHttps 时遇到了重定向循环 (310) 的问题。问题在于，与 EC2 一样，CloudFlare 在将请求转发到服务器之前终止 SSL。但是，虽然 Amazon 设置 X-Forwarded-Proto 标头以便您可以使用自定义过滤器处理请求，但 CloudFlare 似乎没有。或者如果他们这样做了，我不知道他们是如何做到的，因为我无法拦截该级别的流量。我已经尝试过 Amazon EC2 的解决方案，但它们似乎对 CloudFlare 没有帮助。
有没有人遇到过这个问题，或者对 CloudFlare 有足够的了解来提供帮助？
【问题讨论】：
标签：
asp.net-mvc
ssl
appharbor
cloudflare
【解决方案1】：
AppHarbor 的负载均衡器有意将X-Forwarded-Proto 标头覆盖为请求的实际方案。
请注意，虽然 CloudFlare 灵活的 SSL 选项可能会稍微提高安全性，但仍有未加密的流量通过公共互联网从 CloudFlare 传输到 AppHarbor。这可以说违背了 SSL 的目的，除了外观和减少攻击向量的数量（如用户本地网络上的数据包嗅探） - 即它可能对您的用户看起来“专业”，但实际上仍然不安全。
这并不理想，特别是因为 AppHarbor 支持安装您自己的证书并包含开箱即用的搭载 SSL。 CloudFlare 还建议在源服务器/服务支持 SSL 的情况下使用“完整 SSL”。所以你有几个选择：
- 继续使用不安全的“灵活 SSL”选项，但不要检查自定义
RequireHttps 过滤器中的 X-Forwarded-Proto 标头，而应检查 CF-Visitor 标头的 scheme 属性。 this discussion有更多细节。
- 使用“完整 SSL”并将 CloudFlare 指向您的
*.apphb.com 主机名。通过这种方式，您可以使用 AppHarbor 应用程序默认启用的免费搭载 SSL。您必须覆盖 CloudFlare 上的 Host 标头才能使其正常工作和 here's a blog post on how to do that。这当然会使对您的应用程序的请求看起来像是对您的*.apphb.com 域发出的 - 因此，例如，如果您自动将请求重定向到“规范” URL 或生成绝对 URL，您可能必须考虑到这一点。
- 上传您的证书并将自定义主机名添加到 AppHarbor。然后在 CloudFlare 上打开“Full SSL”。这样主机头将保持不变，您的应用程序将继续工作而无需任何修改。您可以在this knowledge base article 中阅读有关 AppHarbor 提供的 SSL 选项的更多信息。
【解决方案2】：
这很有趣。
我最近与我们的一位客户进行了讨论，他向我询问了“灵活” SSL 并建议我们（Incapsula）也提供这种选项。
经过一些讨论，我们都得出这样的结论，即这样的功能会产生误导，因为它会给最终用户带来虚假的安全感，同时也会让网站所有者面临责任索赔。
简单地说，使用“灵活”SSL 连接之一的访问者可能会在加密之后感到绝对安全，并且愿意提供敏感数据，而不知道“服务器到云”路由根本没有加密并且可以被拦截（即通过后门壳）。
参观这里并看到其他人得出相同的结论很有趣。 +1
请注意，作为网站所有者，您可能会对此类设置可能导致的任何不必要的曝光负责。
我的建议是做负责任的事情并投资 SSL 证书，甚至创建一个自签名证书（用于加密“云到服务器”路由）。
【解决方案3】：
或者您可以免费获得由 StartCom 签署的一年免费 SSL 证书并将其上传到 AppHarbor。
然后你就可以收工了，拍拍自己的后背！直到未来一年后您必须购买证书 =)。