SSL 通过 RESTful API 还是通过反向代理？

Question

我正在构建一个只能通过 TLS 访问的 RESTful API。 SSL连接应该在哪里实现？

1. 通过 RESTful API 本身，我的 API 是用 golang 编写的，可以轻松处理 SSL。

2. 通过 SSL 反向代理，这里我使用的是 nginx。

我更喜欢第二种方法，因为 nginx 可以更好地处理缓存和静态交付。

我现在应该只实现我的 API HTTP-only 吗？在我看来，系统是安全的，只要 nginx 反向代理仅提供 SSL 并且我的 API 仅将自身暴露给 nginx。

我不确定是否有第三种方法，而我只保留我的 API SSL 并且 nginx 透明地传递所有请求。

Answer 1

TL;DR：我会根据情况在第二个或第三个选项之间进行选择。如果您想在 Internet 上发布 API，请不要选择第一个。

最安全的选项是第三种：实现您的 API 以仅允许 SSL 连接，并使用反向代理发布到 Internet。

优点是与您的 API 的通信即使对于内部连接也是安全的。这将使您免受内部攻击者的侵害。缺点是服务器上用于管理 SSL 安全性的额外处理负载，这可能会影响性能。

无论如何，您应该寻找成本效益。这就是为什么它将取决于场景的原因。例如，如果您的 API 不会被内部用户访问，而仅用于内部服务，并且服务器上的负载很重，您可以考虑第二种方法：纯 HTTP por 内部通信和 Internet 的 SSL 终止。