HTTPS 安全最佳实践（一）之SSL/TLS部署(5)

4.2 使用 session 恢复

会话恢复是一种性能优化技术，可以节省昂贵的密码操作的结果，并重复使用一段时间。残疾或非功能性会话恢复机制可能会引起显着的性能损失。

4.3 使用 WAN 优化和 HTTP/2

这些天，TLS 开销不是来自 CPU 饥饿的加密操作，而是来自网络延迟。只有在 TCP 握手完成后才能启动TLS握手，需要进一步交换数据包，并且离开服务器的距离更远。最小化延迟的最佳方法是避免创建新的连接 - 换句话说，保持现有的连接长时间（keep-alives）。提供良好结果的其他技术包括支持现代协议（如HTTP / 2）和使用WAN优化（通常通过内容传送网络）。

4.4 隐藏公共内容

通过TLS进行通信时，浏览器可能会认为所有流量都是敏感的。它们通常会使用内存来缓存某些资源，但一旦关闭浏览器，所有内容可能会丢失。为了获得性能提升，并能够长期缓存一些资源，将公共资源（例如图像）标记为公开。

4.5 使用 OCSP Stapling

OCSP 装订是 OCSP 协议的扩展，可以直接从服务器提供撤销信息作为 TLS 握手的一部分。因此，客户端不需要联系 OCSP 服务器进行带外验证，并且总体 TLS 连接时间显着减少。OCSP 装订是一种重要的优化技术，但您应该注意，并不是所有的网络服务器都提供了可靠的 OCSP 装订实现。结合具有缓慢或不可靠的 OCSP 响应者的 CA，这样的 Web 服务器可能会产生性能问题。为了获得最佳效果，请模拟故障条件，看看它们是否会影响您的可用性。

4.6 使用快速加密

除了提供最佳的安全性，我推荐的密码套件配置也提供了最好的性能。尽可能使用支持硬件加速 AES 的 CPU。之后，如果您真的想要进一步的性能优势（大多数网站可能不需要），请考虑使用 ECDSA 密钥。

5 HTTP 和 应用安全

HTTP 协议和 Web 应用交付的周边平台在 SSL 诞生后继续快速发展。作为这一进化的结果，该平台现在包含可用于打败加密的功能。在本节中，我们列出了这些功能，以及安全使用它们的方法。

5.1 加密无处不在

加密是可选的事实可能是今天最大的安全问题之一。我们看到以下问题：

没有 TLS 需要它的网站

具有 TLS 但不执行 TLS 的站点

混合 TLS 和非 TLS 内容的网站，有时甚至在同一网页内

编程错误的网站会颠覆 TLS

尽管如果您确切了解您正在做的事情，许多这些问题可以被缓解，可靠地保护网站通信的唯一方法是无一例外地执行加密。

5.2 消除混合内容

混合内容页面是通过 TLS 传输但是包含不通过 TLS 传输的资源（例如，Java 文件，images，CSS 文件）的页面。这样的页面不安全。一个活跃的中间人（MITM）攻击者可以搭载一个单独的未受保护的 Java 资源，例如劫持整个用户会话。即使您遵循上一节的建议并对整个网站加密，您仍然可能会最终从第三方网站中检索未加密的一些资源。

5.3 使用可信第三方

网站通常使用通过从另一个服务器下载的 Java 代码激活的第三方服务。这种服务的一个很好的例子是 Google Analytics（分析），用于 Web 的大部分。这种包含第三方代码创建一个隐含的信任连接，有效地使对方完全控制您的网站。第三方可能不是恶意的，但是这些服务的大型提供商越来越被视为目标。推理很简单：如果大型提供程序受到威胁，攻击者将被自动访问所有依赖该服务的站点。

如果您遵循第4.2节的建议，至少您的第三方链接将被加密，从而避免 MITM 攻击。但是，您应该进一步了解：了解您使用的服务和删除服务，将其替换为更安全的替代方案，或接受其继续使用的风险。一种称为子资源完整性（SRI）的新技术可用于通过第三方资源来减少潜在的风险。[3]

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-63856-5.html