【问题标题】：TLS, headers and proxies : how to answer the client?TLS、标头和代理：如何回答客户端？
【发布时间】：2014-05-07 07:45:09
【问题描述】：

上下文：

我尝试让自己熟悉网络技术。我最近一直在学习套接字，现在将标准提高到 tcp 服务器。

我有两台服务器：一台前端和一台数据库服务器。前端：nginx 数据库服务器：用于数据库连接的自定义 tcp 服务器。

TLS 加密已激活。

Nginx - Debian 64.

问题：

前端命名为 A，数据库命名为 B。

我想了解如何将 A 作为 ssl 终止点，将请求传递给 B 服务器，最后将查询发送回 A，以便使用 TLS 回答客户端。

据我了解：

1) 客户端请求服务器进行 ssl 握手

2) 服务器接受并根据与之相关的证书执行此操作

3) 客户端进行查询

4) 服务器查看payload并知道它是好的，因为它可能在某处有缓存

5) 但查询必须在 LAN 上代理，以便服务器以明文方式代理请求

6) 另一台服务器将查询和回答返回给前端

7) 前端再次加密整个响应并再次发送给客户端。

7) 是如何发生的？我认为它不能随机重新加密，对吗？它必须在缓存中获取密钥或其他东西，不是吗？

我需要的是对这一点的确认或解释 7)。

【问题讨论】：

【解决方案1】：

7) 是如何发生的？我认为它不能随机重新加密，对吗？它必须在缓存中获取密钥或其他东西，不是吗？

7 通过使用 SSL 握手期间协商的会话密钥加密响应数据来实现。

【讨论】：

谢谢。是否有保存该信息的标头？
从不传输会话密钥。包含自己的解密密钥的加密消息究竟有什么用处？为什么你如此专注于标题？
因为我试图理解它是如何工作的:)。由于有一个会话，它必须在某个地方传递，以便服务器可以说是它客户端 A 或客户端 B...你不能每次都使用随机会话，对吗？
当然不是。会话密钥由两端使用安全密钥协商协议独立计算。如果它与消息一起传输，任何人都可以使用它来解密消息，因此它将完全没有意义并且完全不安全。您似乎真的在问 SSL 是如何工作的，这在此处无法涵盖。有关于它的优秀书籍，以及 RFC（2246 及以下）。