5

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

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

4

3 回答 3

3

X-Forwarded-ProtoAppHarbor 的负载均衡器有意将标头覆盖为请求的实际方案。

请注意，虽然 CloudFlare 灵活的 SSL 选项可能会稍微提高安全性，但仍有未加密的流量通过公共互联网从 CloudFlare 传输到 AppHarbor。这可以说违背了 SSL 的目的，除了外观和减少攻击向量的数量（如用户本地网络上的数据包嗅探） - 即它可能对您的用户看起来“专业”，但实际上仍然不安全。

这不太理想，特别是因为 AppHarbor 支持安装您自己的证书并包括开箱即用的搭载 SSL。CloudFlare 还建议在源服务器/服务支持 SSL 的情况下使用“完整 SSL”。所以你有几个选择：

  • 继续使用不安全的“灵活 SSL”选项，但不要检查X-Forwarded-Proto自定义RequireHttps过滤器中的标头，而应检查标头的scheme属性CF-Visitor。在这个讨论中有更多细节。
  • 使用“完整 SSL”并将 CloudFlare 指向您的*.apphb.com主机名。通过这种方式，您可以使用 AppHarbor 应用程序默认启用的免费搭载 SSL。您必须覆盖HostCloudFlare 上的标头才能使其正常工作，这里有一篇关于如何做到这一点的博客文章。这当然会使对您的应用程序的请求看起来像是对您的*.apphb.com域发出的 - 因此，例如，如果您自动将请求重定向到“规范” URL 或生成绝对 URL，您可能必须考虑到这一点。
  • 上传您的证书并将自定义主机名添加到 AppHarbor。然后在 CloudFlare 上打开“Full SSL”。这样主机头将保持不变，您的应用程序将继续工作而无需任何修改。您可以在此知识库文章中阅读有关 AppHarbor 提供的 SSL 选项的更多信息。
于 2013-04-05T19:04:09.217 回答
0

这很有趣。

就在我最近与我们的一位客户进行了讨论，他向我询问了“灵活” SSL 并建议我们（Incapsula）也提供这种选项。

经过一番讨论，我们都得出结论，这样的功能会产生误导，因为它会给最终用户带来虚假的安全感，同时也会让网站所有者面临责任索赔。

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

参观这里并看到其他人得出相同的结论很有趣。+1

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

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

于 2013-04-08T17:32:06.560 回答
0

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

然后你就可以收工了，拍拍自己的背！那是直到将来你一年后必须购买证书=）。

于 2013-04-11T16:39:10.470 回答