CloudFlare SSL与ASP.NET MVC的兼容性RequireHttps

Question

我在AppHarbor（使用Amazon EC2）上托管ASP.NET MVC 4站点，并且我正在使用CloudFlare进行灵活SSL。尝试使用RequireHttps时，我遇到重定向循环（310）的问题。问题是，与EC2一样，CloudFlare在将请求转发到服务器之前终止SSL。但是，尽管Amazon设置了X-Forwarded-Proto标头，以便您可以使用自定义过滤器处理请求，但CloudFlare似乎并未显示。或者如果他们这样做，我不知道他们是怎么做的，因为我无法拦截那个级别的流量。我已经尝试了Amazon EC2的解决方案，但他们似乎没有帮助CloudFlare。

有没有人遇到过这个问题，或者对CloudFlare有足够的了解？

Answer 1

的X-Forwarded-Proto头故意AppHarbor的负载平衡器重写该请求的实际方案。

注意的是，虽然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域进行的 - 因此，如果您自动将请求重定向到“规范”网址或生成绝对网址，您可能必须考虑此问题。
• 上传您的证书并将自定义主机名添加到AppHarbor。然后在CloudFlare上打开“完整SSL”。这样主机头将保持不变，您的应用程序将继续工作而不做任何修改。您可以在this knowledge base article中阅读更多关于AppHarbor提供的SSL选项的信息。

Answer 2

这很有趣。

只是我最近有一个讨论，与我们的客户，谁问我关于“灵活” SSL和建议，我们（Incapsula）也提供这样的选项之一。

经过一番讨论后，我们都得出的结论，这样的功能会产生误导，因为它会提供最终用户提供安全的错觉，同时也暴露了网站所有者的责任索赔。

简而言之，访问者在“灵活”SSL连接之一可能感觉绝对安全，并愿意提供敏感数据，而不知道“服务器到云”路由根本没有加密，可以截获（即通过后门外壳）。

有趣的是，在这里访问并看到其他人达到相同的结论。 +1

请注意，作为网站所有者，您可能需要承担此类设置可能导致的任何不必要的曝光。

我的建议是做负责任的事情，并投资于SSL证书，甚至创建一个自签名的（用于加密'云服务器'路线）。

Answer 3

或者您可以获得由StartCom签名的免费一年SSL证书并将其上传到AppHarbor。

然后，你可以称它为一天，并在后面拍拍自己！这是直到将来你从现在开始购买证书=）。