我们有一个(Linux)服务器运行两个进程，A 和 B。目前，客户端建立到进程 A 的连接，然后将生成的套接字的文件描述符传递给进程 B，允许进程 B 使用现有的 fd/socket与客户无缝沟通。客户端和进程 B 然后执行 TLS 握手并继续讨论生成的 TLS 连接。
(我在这里省略了很多细节，但是是的，有一个很好的理由让进程 A 充当中介而不是直接连接到进程 B)
现在，因为 <long complicated story involving new client applications and websockets> 看来我们可能要在进程A中进行TLS握手，然后将建立的TLS连接传递给进程B。
这可能吗？底层套接字的文件描述符可以被复制(我们已经这样做了)，至少在理论上，内部 TLS 状态数据也可以被复制并用于重建进程 B 中的 TLS 连接，有效地接管连接。
但是 OpenSSL 会公开任何类似的设施吗？
我找到了函数 d2i_SSL_SESSION这似乎对 OpenSSL session 对象做了类似的事情，但对 OpenSSL 来说是很新的，我不确定这是否足够。涉及 session 、上下文、BIO 和其他一些听起来很复杂的术语。有多少必须序列化并传输到进程 B 才能使其工作？在实践中将如何完成？
切换需要对客户端 100% 透明:它必须简单地对给定的 IP/端口执行 SSL 握手，然后继续在生成的套接字上对话，而不知道一个进程接受了这个事实连接并执行 TLS 握手，然后另一个处理所有后续通信。
最佳答案
跨进程共享 SSL 上下文确实是可能的。然而，SSL-session-context 需要驻留在两个进程都可以访问的共享内存位置(因为具体原因未知)我们希望在进程 A 中完成实际的握手并进行数据 I/O在进程B中。
第一步是注册回调 SSL_CTX_sess_set_new_cb(ctx, shared_ctx_new_cb); SSL_CTX_sess_set_get_cb(ctx, shared_ctx_get_cb); SSL_CTX_sess_set_remove_cb(ctx, shared_ctx_remove_cb);
确保始终在共享内存中创建适当的 SSL session 上下文(或至少返回一个序列化并准备好使用指向 SSL_SESSION 的可寻址指针
要(反)序列化 SSL_SESSION 'C' 结构，请使用可用的 API d2i_SSL_SESSION(...) 和 i2d_SSL_SESSION(...)
一个使用这种方法的工作项目，示例代码位于 https://github.com/varnish/hitch/blob/master/src/shctx.c
关于c++ - OpenSSL:接受TLS连接，然后转移到另一个进程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12426246/