反向代理或服务器本身是否应该解析 https

Question

情况如下：

我的机器上运行着两台服务器。一台是面向外部的服务器，另一台是反向代理，它只监听本地主机并提供​​服务。

第二台服务器应该运行https。我知道有两个选项：

1. 只需在第二台服务器上实现https，并让反向代理向其提供 https 包。
2. 在反向代理中实现https逻辑并为第二台服务器“抽象 https”。

我甚至不知道这两种选择是否可行，更不用说是否可行了。如果可行，这两种解决方案的优缺点是什么？

编辑：在这种情况下，反向代理是 nginx，并且服务提供服务器是一个 Node.js 服务器。

Answer 1

我推荐你的方案二。使用专用服务器来处理 ssl / tls 内容是一种很好的做法。

当您的软件设计开始变得更加广泛时，您可能需要在两个 NodeJS 实例之间进行负载平衡。在这种情况下，当反向代理可以查看传输的数据时（只有当它自己进行加密时才能够查看），更容易实现会话粘性和类似的东西

如果您预计您的设计会发生变化，并且反向代理和 NodeJS 实例将被移动到单独的服务器，那么您应该从一开始就规划加密，因为否则您将通过网络传输未加密的数据。

由于我们都位于德国：我经常看到编写的软件不支持加密，这在德国安全官员要求 100% 加密的环境中使用时会导致严重问题，即使您“仅”传输会话数据。因此，根据您的计划，您应该仔细考虑哪个更受重视：简单性还是安全性。

Answer 2

在代理中使用 https 还有另一个优点：您以后可以将网站的各个部分移动到不同的服务器，同时保留一个面向用户的域和一个证书。