我们有一个（Linux）服务器运行两个进程A和B。当前，客户端建立到进程A的连接，然后进程A将生成的套接字的文件描述符传递给进程B，允许进程B使用现有的fd/socket进行无缝通信与客户。然后，客户端和进程 B 执行 TLS 握手并继续在生成的 TLS 连接上进行对话。
（我在这里省略了很多细节，但是，是的，那里is让进程 A 充当中介而不是直接连接到进程 B 的充分理由）
现在，因为<long complicated story involving new client applications and websockets>看起来我们可能必须在进程A中执行TLS握手，然后将已建立的TLS连接传输给进程B。
那可能吗？底层套接字的文件描述符可以被复制（我们已经这样做了），并且至少在理论上，内部 TLS 状态数据也可以被复制并用于重建进程 B 中的 TLS 连接，从而有效地接管连接。
但是 OpenSSL 是否公开了类似的设施？
我找到了这个功能d2i_SSL_SESSION这似乎对 OpenSSL 会话对象做了类似的事情，但对于 OpenSSL 来说还很陌生，我不确定这是否足够。其中涉及会话、上下文、BIO 和其他一堆听起来很复杂的术语。需要序列化多少数据并将其传输到进程 B 才能正常工作？在实践中又会如何实现呢？
切换要求对客户端 100% 透明：它必须简单地针对给定的 IP/端口执行 SSL 握手，然后继续在生成的套接字上进行通信，而不知道一个进程接受连接并执行的事实TLS 握手，然后另一个处理所有后续通信。
跨进程共享 SSL 上下文确实是可能的。但是，SSL 会话上下文需要驻留在两个进程都可以访问的共享内存位置（因为具体原因未知），我们希望实际握手在进程 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 会话上下文（或者至少返回一个序列化且准备使用的指向 SSL_SESSION 的可寻址指针
要（反）序列化 SSL_SESSION 'C' 结构，请使用可用的 API d2i_SSL_SESSION(...) 和 i2d_SSL_SESSION(...)
使用此方法的工作项目示例代码位于https://github.com/varnish/hitch/blob/master/src/shctx.c https://github.com/varnish/hitch/blob/master/src/shctx.c
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
