c - 如何在一个进程中接受 SSL 连接并在另一个进程中重用相同的 SSL 上下文

Question

我花了很多时间研究如何解决这个问题，但还没有找到可行的解决方案。

问题:我正在使用 OpenSSL 库和 Linux。我有一个服务器进程 P1 接受来自 SSL 客户端的 SSL 连接。 P1 执行 tcp_accept()，然后执行 SSL_accept()，并使用 SSL_read/SSL_write() 与客户端交换一些协议(protocol)数据。到目前为止一切都很好。现在，根据设计，P1 需要派生一个子进程 C1 以从此点开始为客户端提供服务。 C1 使用 execve 调用重新镜像自身并生成不同的二进制文件。 C1 仍然需要通过 P1 中使用的相同 SSL 连接与 SSL 客户端通信。问题是因为 C1 现在是一个完全不同的进程，它如何为该客户端重新使用现有的 SSL 连接？我能够将底层 TCP 套接字描述符从 P1 传递到 C1，因为它在内核中维护，但我无法传递 SSL 上下文，因为它在 Openssl 库中维护。

我在 stackoverflow 上看到了这个步骤，但不幸的是没有提到解决方案。 OpenSSL: accept TLS connection and then transfer to another process

可能的解决方案:我不确定是否有人已经解决了此类问题，但我尝试了以下操作。

1. 我想我可以创建一个新的 SSL 上下文并在新的子进程中进行 SSL 重新协商。因此，在 C1 中，我在相同的底层 tcp 套接字 fd 上创建了一个新的 SSL 上下文，并尝试进行 SSL 重新协商。这是我所做的(省略了 SSL_ctx 初始化部分)

   ssl = SSL_new(ctx)//ctx 的初始化与在 P1 服务器中所做的相同
   SSL_set_fd(ssl, fd);//fd 是从 P1 传递到 C1 的底层 tcp 套接字 fd
   SSL_set_accept_state(ssl);
   SSL_set_verify(ssl, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, 0);
   SSL_renegotiate(ssl);
   SSL_do_handshake(ssl);
   ssl->state=SSL_ST_ACCEPT;
   SSL_do_handshake(ssl);

但是重新协商没有成功，并且从第一次 SSL_do_handshake() 调用中返回给我一个 Openssl 内部错误。我什至不确定这是否真的可以做到。我能想到的另一个解决方案如下。

1. 以某种方式将该客户端的整个 SSL 上下文从 P1 传输到 C1。这样做的效率如何？我可以为此考虑共享内存，但不确定 OpenSSL 维护的所有内部状态需要复制到共享内存中。这似乎是最合乎逻辑的解决方案，但我对执行此操作的 OpenSSL 代码没有太多了解。

有人遇到过类似的问题并解决了吗？我将非常感谢有关此的任何帮助。

非常感谢

Answer 1

在线搜索找到此讨论:

Passing TLS sessions between programs

Once you have the SSL_SESSION, convert it to ASN1 (via i2d_SSL_SESSION) and dump it to a file. Read that file in with your second program and convert it back from ASN1 to SSL_SESSION(via d2i_SSL_SESSION) and add it to the SSL_SESSION cache of the SSL_CTX (via SSL_CTX_add_session).

I found in doc/ssleay.txt :
[...]
The PEM_write_SSL_SESSION(fp,x) and PEM_read_SSL_SESSION(fp,x,cb) will write to a file pointer in base64 encoding. What you can do with this, is pass session information between separate processes.
[...]

因此您需要序列化来自 P1 的 SSL session 数据并将其与套接字描述符一起传递给 C1 进行反序列化。然后，您可以在 C1 中创建新的 SSL 和 SSL_CTX 对象，并将它们与套接字和反序列化的 session 数据相关联，以便 C1 可以接管对话。