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

Question

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

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

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

(3)对于父服务器进程和请求处理进程之间的通信，利用sendmsg() - SCM_RIGHTS技术，建立了进程间通信机制，将打开的套接字描述符从父服务器进程复制到请求处理进程。

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

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

重点是，我不想浪费在服务器和请求处理过程之间传输数据的任何性能。我也不想在每个请求的基础上产生请求处理过程。因此，我想提前生成请求处理过程。

虽然我真的不确定我在这里尝试的东西对你们是否有意义，但如果你们中的任何人能给我一些关于上述方法是否可行的提示，我将不胜感激。

Answer 1

目前还不清楚您到底在寻找什么，特别是您希望在哪里进行SSL加密/解密。

是否要在请求处理程序进程内进行加密/解密？

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

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

您是否希望主进程对请求处理程序进程执行加密/解密？

在这种情况下，将原始套接字传递给请求处理程序进程是没有意义的，因为它们从该套接字获得的唯一东西是加密数据。在该场景中，您必须打开到后端进程的新连接，因为它将携带不同的数据(解密)。然后，主进程将从网络套接字读取加密数据，对其进行解密，并将结果写入请求处理程序的新套接字。在另一个方向上也是如此。

注意:如果你只是想让你的请求处理过程根本不用担心SSL，我建议让他们监听回送接口，并使用像stud这样的东西来做SSL/TLS的脏活。

简而言之，你必须在上面两个中选择一个。不可能同时做这两件事。