title: OpenSSL: accept TLS connection and then transfer to another process
body: <p>We have a (Linux) server running two processes, A and B. Currently, clients establish a connection to process A, which then passes the resulting socket's file descriptor to process B, allowing process B to use the existing fd/socket to communicate seamlessly with the client. The client and process B then perform a TLS handshake and continue talking on the resulting TLS connection.</p>
  
  <p>(I'm leaving out a lot of details here, but yes, there <em>is</em> a good reasons for having process A act as an intermediary instead of just connecting to process B directly)</p>
  
  <p>Now, because of <em><code>&lt;long complicated story involving new client applications and websockets&gt;</code></em> it looks like we may have to perform the TLS handshake in process A, and then transfer the established TLS connection to process B.</p>
  
  <p>Is that possible? The underlying socket's file descriptor can be copied (we do that already), and at least in theory, the internal TLS state data could also be copied and used to reconstruct the TLS connection in process B, effectively taking over the connection.</p>
  
  <p>But does OpenSSL expose any facility like that?
  I found the function <code>d2i_SSL_SESSION</code> which seems to do something similar for an OpenSSL session object, but being quite new to OpenSSL, I'm not sure if that is sufficient. There are sessions, context, BIO's and a bunch of other complicated-sounding terms involved. How much would have to be serialized and transferred to process B for this to work? And how would it be done in practice?</p>
  
  <p>The switchover is required to be 100% transparent to the client: it must simply perform an SSL handshake against a given IP/port, and then continue talking on the resulting socket, with no knowledge of the fact that one process accepts the connection and performs the TLS handshake, and another then handles all subsequent communication.</p>