我已经阅读，即在Rackspace ，一个不应该使用SSLterminal的敏感信息（search页面“SSL终止不应该使用”）。 首先，为什么会这样呢？ 其次，如果您不能相信数据安全运输，那么世界上拥有SSL的价值是什么？
我对第一个问题的猜测是，如果有人知道服务器的直接IP，完全绕过负载均衡器，然后进入端口80，那么可以添加带有HTTPS URL的X-Forwarded-For头。我可以克服那通过iptables（只允许从负载平衡器端口80），对不对？
注意：我的服务器与负载均衡器在同一个专用networking中（关于Rackspace文章中的“安全问题是什么”）。
他们告诉你的是，如果你select让SSL端点到达负载均衡器（而不是负载均衡器路由到的服务器），那么你应该知道，不pipe数据安全性如何在通往负载均衡器的路上，一旦它离开负载均衡器，它就处于清除状态。 在私人数据中心，将SSL处理卸载到负载平衡器或专用硬件并不罕见，然后将内部pipe道（以前包装在SSL中的那个）继续到普通的Web服务器进行维护。
他们给出的警告是，如果您的云服务器与您的负载均衡器不在同一个数据中心，那么如果您在负载平衡器中打开ssl会话，则从它们到web服务器的stream量将是透明的并通过公共networking路由。
至于你对X转发的东西的猜测，你误解了他们的意思。 他们说，如果您的Web服务要确保客户端正在使用SSL，但是您正在剥离负载平衡器上的SSL包装器，那么他们可以让负载平衡器为您的Web服务器附加一个额外的标头，以便您知道客户端DID使用SSL，即使您的networking服务器会说没有使用SSL。
希望能帮助你
你提到的机架空间文件有点不清楚，但我相信这个意图是这样的：
您希望尽可能使用SSL的敏感信息。 （从客户端到数据库的所有path）
如果您在负载平衡器层启用了SSL终止，则安全性在此处停止。 （敏感数据将在您的负载平衡器层和应用层之间以明文forms传输。）
我相信这是文档中的意图。 您应该避免任何未encryption的敏感数据传输。
是的，你可能在同一个“私人networking”，但你的客户将更好地服务端到端的encryptionstream量。
祝你好运。