为什么不对所有内容都使用HTTPS？

如果我正在设置服务器并获得SSL证书，为什么我不对整个站点使用HTTPS而不是仅仅用于购买/登录？我认为仅加密整个站点并完全保护用户会更有意义。这样可以防止出现诸如决定必须保护什么内容之类的问题，因为这一切都应该是事实，这对用户而言并不是真正的麻烦。

如果我已经在网站的一部分上使用HTTPS，为什么不希望在整个网站上使用它？

这是一个相关的问题：为什么https仅用于登录？，但答案并不令人满意。答案假设您无法将https应用于整个网站。

我可以想到几个原因。

• 某些浏览器可能不支持SSL。
• SSL可能会降低性能。如果用户正在下载大型的公共文件，则每次加载这些文件都会给系统带来负担。

除了其他原因（尤其是与性能有关）之外，使用HTTPS时，每个IP地址*只能托管一个域。

单个服务器可以在HTTP中支持多个域，因为服务器 HTTP标头使服务器知道响应哪个域。

使用HTTPS，服务器必须在初始TLS握手期间（即HTTP启动之前）将其证书提供给客户端。这意味着尚未发送服务器标头，因此服务器无法知道请求哪个域以及响应哪个证书（www.foo.com或www.bar.com）。

*注：从技术上讲，如果将多个域托管在不同的端口上，则可以托管多个域，但这通常不是一个选择。如果您的SSL证书带有通配符，则您也可以托管多个域。例如，您可以使用证书* .example.com托管foo.example.com和bar.example.com。

SSL / TLS的使用率几乎不足。整个会话必须使用HTTPS ，绝不能通过HTTP发送会话ID。如果仅使用https登录，则明显违反OWASP 2010年 “ A3：身份验证和会话管理中断”的前10名。

为什么不通过挂号邮件在防篡改的不透明信封中发送每个蜗牛邮件？邮局的某人总是会亲自保管它，因此您可以确定没有人偷窥您的邮件。显然，答案是虽然有些邮件值得花销，但大多数邮件却不值得。我不在乎是否有人读过我的“高兴你从监狱出来！” 给乔叔叔的明信片。

加密不是免费的，而且并不总是有用。

如果要使用HTTPS结束会话（例如购物，银行等），则没有充分的理由不使整个会话尽可能早地使用HTTPS。

我的观点是，仅应在不可避免的必要情况下使用HTTPS，因为需要保护请求或响应以免受到中间监听。举个例子，看看Yahoo! 主页。即使您已登录，您的大部分交互也会通过HTTP进行。您通过HTTPS进行身份验证，并获得可证明您身份的Cookie，因此您无需HTTPS即可阅读新闻报道。

除了系统负载之外，最大的原因是它破坏了基于名称的虚拟主机。使用SSL，它是一个站点-一个IP地址。这是相当昂贵的，而且较难管理。

对于高延迟链路，初始TLS握手需要额外的往返行程，以验证证书链（包括发送任何中间证书），就密码套件达成协议并建立会话。建立会话后，后续请求可以利用会话缓存来减少往返次数，但是即使在这种最佳情况下，往返次数仍然比正常HTTP连接所需的次数更多。即使加密操作是免费的，也不是这样，并且在较慢的网络链接上也很明显，尤其是在站点不利用http流水线的情况下。对于网络连接良好的网段中的宽带用户而言，这不是问题。如果您在国际上开展业务，则https会很容易引起明显的延迟。

还有其他一些考虑因素，例如会话状态的服务器维护，可能需要大量内存，当然还有数据加密操作。实际上，任何小型站点都不必担心给定的服务器功能与当今硬件的成本。任何大型站点都可以轻松承担CPU / w AES卸载或附加卡的费用，以提供类似的功能。

随着时间的流逝以及硬件和网络功能的提高，所有这些问题变得越来越不成问题。在大多数情况下，我怀疑今天是否存在明显的差异。

可能存在操作上的考虑，例如对https流量的管理限制（请考虑使用中间内容过滤器等），可能还需要一些公司或政府法规。一些公司环境要求在外围进行数据解密，以防止信息泄漏……干扰热点和类似的基于Web的访问系统，这些访问系统无法在https事务中注入消息。在我看来，归根结底，默认情况下不使用https的原因可能很小。

https比普通的http占用更多资源。

服务器和客户端都需要更多。

如果整个会话都被加密，那么您将无法对代理级别（例如ISP）上的图像和js等静态资源使用缓存。

您应该在所有地方都使用HTTPS，但是会丢失以下内容：

1. 由于BREACH和CRIME攻击，您绝对不应使用SSL压缩或基于SSL的HTTP压缩。因此，如果您的响应包含会话或csrf标识符，则无需压缩。您可以通过将静态资源（图像，js，css）放在无cookie的域上并在其中使用压缩来减轻这种情况。您也可以使用HTML缩小。

2. 除非使用SNI，否则一份SSL证书，一个IP地址，除非在所有浏览器（旧版android，blackberry 6等）上都无法使用，

3. 您不应该在网页上托管任何非SSL的外部内容。

4. 当浏览器转到HTTP页面时，您会丢失出站HTTP Referer标头，这对您来说可能是问题，也可能不是问题。

好吧，显而易见的原因是性能：所有数据都必须在传输之前由服务器加密，然后在客户端收到后解密，如果没有敏感数据，这是浪费时间。它还可能会影响您的网站缓存了多少。

如果所有地址都使用https://而不是熟悉的地址，也可能使最终用户感到困惑http://。另外，请参见以下答案：

为什么在包含js文件时不总是使用https？

https要求服务器加密和解密客户端请求和响应。如果服务器为许多客户端提供服务，则对性能的影响将加在一起。因此，https的大多数当前实现仅限于密码身份验证。但是随着计算能力的提高，在所有Gmail都在整个网站上都使用SSL之后，这种情况可能会改变。

除了WhirlWind的响应之外，您还应该考虑SSL证书的成本和适用性，访问问题（客户端不太可能通过SSL端口进行通信，这很可能，尽管不太可能），等等。

使用SSL不能保证一定的安全性。这种保护类型需要内置到应用程序的体系结构中，而不是试图依靠一些魔术。

有人告诉我，在我们公司的一个项目中，他们发现SSL消息占用的带宽明显大于普通消息。我相信有人告诉我，这是惊人的12倍的数据。我自己尚未对此进行验证，这听起来很高，但是如果在每个页面上都添加了某种标题，并且大多数页面上的内容很少，那么可能还不算太远。

也就是说，在http和https之间来回移动并跟踪哪些页面是我的工作似乎很麻烦。我只曾经尝试建立一个将它们混合在一起的站点，但是当我们被诸如Javascript创建的弹出窗口之类的复杂事情绊倒时，我们最终放弃了该计划。我们最终只是使整个站点https减少了麻烦。我猜在简单的情况下，您只有一个需要保护的登录屏幕和付款屏幕，而且它们是简单的页面，所以混搭并不大。

我不必担心客户端解密的负担。通常，客户端等待数据通过网络的时间要比处理数据花费的时间更多。在用户没有常规的千兆位/秒的互联网连接之前，客户端的处理能力可能是不重要的。服务器要求用于加密页面的CPU能力是另一个问题。它可能无法跟上成百上千的用户。

还有一点（也许有人可以验证），如果用户在表单项（例如文本框）中键入数据，然后由于某种原因刷新页面或服务器崩溃了一秒钟，则用户输入的数据将丢失HTTPS，但使用HTTP保留。

注意：我不确定这是否是特定于浏览器的，但是我的Firefox浏览器肯定会发生这种情况。

带有IIS 8.0的Windows Server 2012现在提供SNI，即服务器名称指示，它允许将IIS中的多个SSL Web应用程序托管在一个IP地址上。