带非 TLS 后端的 HTTPS 负载平衡器和带 TLS 后端的 HTTPS 负载平衡器有什么区别

Question

我正在尝试将load balancer 配置为使用Lets Encrypt 提供的证书在HTTPS 中服务，即使我还不能这样做，阅读此article 提供了如何配置的步骤

• 自签名证书
• 带 TLS 后端的网络负载均衡器
• 带有非 TLS 后端的 HTTPS 负载平衡器
• 带有 TLS 后端的 HTTPS 负载平衡器

由于我只对 HTTPS 感兴趣，我想知道这两者之间有什么区别：

1. 带有非 TLS 后端的 HTTPS 负载平衡器
2. 带有 TLS 后端的 HTTPS 负载平衡器

但我的意思不是第一个没有从负载均衡器到后端加密的明显原因，我的意思是在性能和​​ HTTP2 连接方面，例如我会继续从http2 中获得所有好处，比如多路复用和流式传输?或者是第一个选项

带有非 TLS 后端的 HTTPS 负载平衡器

只是一种错觉，但我不会得到 http2？

Answer 1

要使用 HTTP/2，所有 Web 浏览器都需要使用 HTTPS。即使没有 HTTP/2，出于各种原因使用 HTTPS 仍然很好。

因此，您的网络浏览器需要与之通信的点（通常称为 边缘服务器）需要启用 HTTPS。这通常是一个负载平衡器，但也可以是一个 CDN，或者只是一个应用程序服务器前面的单个Web 服务器（例如 Apache） >（例如 Tomcat）。

那么问题是从那个边缘服务器到任何下游服务器的连接是否需要启用HTTPS？好吧，最终浏览器不会知道，所以不适合它。那么加密此连接的原因有两个：

1. 因为流量仍在通过不安全的通道传输（例如 CDN 到源服务器，通过 Internet）。

   许多人认为让用户认为他们处于安全状态（带有绿色挂锁）是不诚实的，但实际上他们并不适合完整的端到端连接。

   如果您的负载平衡器与其连接的服务器位于隔离的网络区域（甚至可能在同一台机器上！），这对我来说不是问题。例如，如果负载均衡器和 2 个（或更多）网络服务器正在连接，它们都位于 DMZ 隔离网络中的单独区域或它们自己的 VPC 中。

   最终，流量会在某个时候被解密，而服务器所有者的问题是，在您的网络堆栈中的什么位置/时间发生了什么，以及您对它的适应程度。

2. 因为您出于某些其他原因需要 HTTPS（例如，一直使用 HTTP/2）。

   在这个问题上，我认为没有什么好的案例可以做。 HTTP/2 主要有助于高延迟、低带宽的连接（即浏览器到边缘节点），而对于低延迟、高带宽的连接（如 Web 服务器的负载均衡器通常是）不太重要。我对this question discusses this more的回答。

在上述两种情况下，如果您在下游服务器上使用 HTTPS，则可以使用自签名证书或长期自签名证书。这意味着您不受 30 天 LetsEncrypt 限制的约束，也不需要您从另一个 CA 购买更长的证书。由于浏览器永远不会看到这些证书，您只需要您的负载均衡器信任它们，这是您可以控制的自签名证书。如果下游 Web 服务器无法与 LetsEncrypt 通信以从那里获取证书，这也很有用。

如果始终使用 HTTPS 和/或 HTTP/2 真的很重要，第三个选项是使用 TCP 负载平衡器（这是您问题中的选项 2，因此很抱歉混淆了这里的编号！） .这只是将 TCP 数据包转发到下游服务器。数据包可能仍然是 HTTPS 加密的，但负载均衡器并不关心 - 它只是转发它们，如果它们是 HTTPS 加密的，则下游服务器的任务是解密它们。因此，在这种情况下您仍然可以使用 HTTPS 和 HTTP/2，您只需在下游 Web 服务器上拥有最终用户证书（即 LetsEncrypt 证书）。这可能很难管理（是否应该在两者上使用相同的证书？或者他们应该有不同的证书？我们是否需要有粘性会话，以便 HTTPS 流量始终到达 sae 下游服务器）。这也意味着负载均衡器无法看到或理解任何 HTTP 流量——就它而言，它们都只是 TCP 数据包。因此，无需过滤 HTTP 标头，或添加新的 HTTP 标头（例如，带有原始 IP 地址的 X-FORWARDED_FOR。）

老实说，在负载平衡器上使用 HTTPS 并在下游服务器上使用 HTTP 流量是绝对可以的，甚至很常见——如果在两者之间的安全网络中。它通常是最容易设置的（一个管理 HTTPS 证书和续订的地方）和最容易支持的（例如，一些下游服务器可能不容易支持 HTTPS 或 HTTP/2）。通过使用自签名证书或 CA 颁发的证书在此连接上使用 HTTPS 同样可以，但需要更多的努力，而 TCP 负载平衡器选项可能是最努力的。