亚马逊显然认为 TLS 的开销足够高，足以证明在不执行敏感操作（如下订单、支付处理、账户管理、订单历史记录、登录等）时不加密流量是合理的。虽然 TLS 的服务器端成本与今天的硬件相比几乎微不足道，但它的成本仍然不为零。客户端的影响可能会更糟，尤其是在高延迟或不可靠的链接（如某些移动连接）上；TLS 可能会导致页面加载显着延迟，从而导致客户转向其他地方。

我个人认为，最好对所有流量使用 TLS，除非你有理由不这样做——而且其中并不多，我不会称之为有效——但我是安全人员首先。亚马逊的存在是为了赚钱，而不是成为安全 Web 开发的榜样。如果始终使用所有 TLS 的成本比使用 HTTP 有时成本更高，那么他们会选择第二种选择，即使这会使他们的客户暴露于某些类型的攻击。

此类风险的一个示例：虽然登录表单是通过 HTTPS 提供的，但将您带到那里的按钮是通过 HTTP 提供的。攻击者可以使用SSL 剥离攻击来修改主页，使登录按钮链接到 HTTP 而不是 HTTPS，然后攻击者可以在用户尝试登录时欺骗登录页面。然后攻击者会看到用户的凭据。亚马逊可以通过使用Strict-Transport-Securityheader来防止这种情况发生，但是他们必须一直通过 HTTPS 为整个站点提供服务。

作为安全榜样，亚马逊在某些方面做得非常好。例如，他们的SigV4方案为 AWS 提供了身份验证、完整性和重放攻击限制。很好的是，假设请求或响应中没有固有的敏感数据（信用卡号本身就是敏感的；映射到信用卡号的标识符字符串不是），实际上不使用 TLS 是安全的AWS 功能（尽管通常它们对大多数 AWS 都要求 TLS）。然而，他们的零售网站为了获得更多利润而做出了一些权衡，牺牲了一点安全性。

如果您想效仿亚马逊的商业成功，那么复制他们的安全选择可能是明智之举……但也要记住，Amazon.com 零售网站已经过时，并且多年来经历了很多变化，增加了更多和更多的安全性。考虑到他们在网站上的任何停机时间花费了多少，他们可能会非常犹豫是否比他们需要的更多的时间来搞乱它。如果他们今天从头开始设计网站，他们很可能会为所有事情使用 TLS，并预加载 HSTS。或许他们不会；毕竟，我确信他们已经考虑过这样做，并且有理由（尚未）实施它。

最后一点：该站点当然始终通过 HTTPS 运行。我的浏览器实际上默认为零售网站使用 HTTPS，即使我以前没有在这台计算机上使用过它，当然也没有登录或任何其他东西。请不要成为那些将用户从 HTTPS 重定向回 HTTP 的站点之一（看着你，Slashdot），即使用户特别喜欢使用 HTTPS。

如果你看看谷歌，他们在 2011 年从 HTTP 切换到 HTTPS，因此当然可以服务大量请求。也许亚马逊的人只是速度较慢，服务器更多，官僚主义更多，或者认为使用旧设备/浏览器的少数人更重要。

此外，现在很难将 HTTPS 设为默认值，因为当前的浏览器会首先将输入域名的每个请求启动到 HTTP，然后再重定向到 HTTPS，这会受到 MITM 的攻击。