linux - 使用 libssl 和 sendmsg() SCM_RIGHTS 实现 SSL 服务器

Question

我现在想知道我们是否可以在 Linux 环境下基于以下策略/方案制作某种 SSL 服务器。

(1)至于初始请求，应该是在父服务器进程中传入的。在建立 SSL 连接并处理请求的初始解析后，请求(套接字)将被转发到请求处理进程以进行进一步处理。

(2) 请求处理过程应该是事先运行的。从这个意义上说，我们不会在这里使用任何基于 fork-exec-pipe 的方案。

(3) 对于父服务器进程和请求处理进程之间的通信，已经建立了一些IPC，以便通过使用sendmsg()将打开的套接字描述符从父服务器进程复制到请求处理进程—— SCM_RIGHTS 技术。

(4) 在SSL功能方面，我们应该使用OpenSSL(libssl)。

(5) 在请求处理过程中，我们应该使用来自父服务器进程的共享套接字描述符来创建新的 SSL 套接字。

关键是我不想浪费在服务器和请求处理进程之间传输数据的任何性能。我也不想根据请求生成请求处理过程。所以我想提前生成请求处理过程。

虽然我不太确定我在这里所做的尝试是否对您有意义，但如果您能给我一些关于上述方法是否可行的提示，我们将不胜感激。

Answer 1

不清楚您到底在寻找什么，尤其是您想在哪里进行 SSL 加密/解密。

您想在请求处理程序进程中进行加密/解密吗？
这似乎是更可能的解释。但是，您谈论在主进程中进行一些请求解析。在主进程中解析的数据是否已经是 SSL session 的一部分？如果是这样，您将必须在主进程中进行 SSL 握手(初始化和 key 交换)才能访问加密数据。如果您随后将原始套接字传递给另一个进程，它将无法访问父进程的 SSL 状态，因此它无法在父进程停止的地方继续解密。如果它试图在套接字上重新初始化 SSL，就好像它是一个干净的连接一样，客户端可能(正确地)将连接中间的未经请求的握手视为协议(protocol)错误并终止连接。如果没有，则会出现安全漏洞，因为攻击者可能会恶意重定向客户端的网络流量，而不是强制重新初始化的请求处理进程。通常不可能将初始化的 SSL session 传递给不同的进程，而不同时通知它们 OpenSSL 的完整内部状态(交换的 key 、一些序列号等)，如果不是不可能的话，这将是很难的。

如果您不需要接触父进程中的 SSL session ，并且您只解析一些在实际 SSL session 开始之前出现的未加密数据(类似于 IMAP 中的 STARTTLS 命令)，您的想法将毫无问题地工作.只需阅读您需要的内容，直到 SSL 交换应该开始的地方，然后使用 SCM_RIGHTS 将套接字传递给后端进程(参见例如 cmsg(3) 或 this site 中的示例)。还有一些图书馆可以为您完成这项工作，即 libancillary .

或者您希望主进程为请求处理进程进行 SSL 加密/解密？
在那种情况下，将原始套接字传递给请求处理程序进程是没有意义的，因为它们唯一能从中获得的是加密数据。在这种情况下，您必须打开一个到后端进程的新连接，因为它将携带不同的数据(已解密)。然后主进程将从网络套接字中读取加密数据，解密并将结果写入请求处理程序的新套接字。从另一个方向类推。

注意:如果您只想让您的请求处理过程完全不用担心 SSL，我建议让它们监听环回接口(interface)并使用类似 stud 的东西。做 SSL/TLS 肮脏的工作。

简而言之，您必须选择以上一项。不可能同时进行这两项操作。