Request for Assistance in TLS Implementation for Our product Networking

During process of enabling TLS communication for our product networking, 
involves client-server communication between two different process sites, 
where they connect and exchange data. We are implementing this solution on 
RHEL Linux using OpenSSL.

Client Initialization: The BIS client initializes the OpenSSL library, 
creates an SSL context, opens a TCP socket to connect to the server, 
creates an SSL structure, and performs the TLS handshake.
Below are OpenSSL API flow sequence:

OPENSSL_init_ssl(0, NULL);
tlsOutboundMethod = TLS_client_method();
sslContextHandle = SSL_CTX_new(tlsOutboundMethod);
SSL_CTX_clear_mode(sslContextHandle, SSL_MODE_AUTO_RETRY);
SSL_CTX_set_min_proto_version(sslContextHandle, TLS1_3_VERSION);
SSL_CTX_set_max_proto_version(sslContextHandle, TLS1_3_VERSION);
SSL_CTX_set_options(sslContextHandle, SSL_OP_NO_COMPRESSION);
SSL_CTX_set_ciphersuites(sslContextHandle, 
"TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256");
SSL_CTX_set_ecdh_auto();
SSL_CTX_use_certificate_file();
SSL_CTX_use_PrivateKey_file();
SSL_CTX_check_private_key();
SSL_set_fd();
SSL_connect();
Server Daemon: The remote server daemon listens on port port 8445 for TLS 
connections.

Server Initialization: The server initializes the OpenSSL library, creates 
an SSL context, listens for and accepts connections, creates an SSL 
structure, and performs the TLS handshake with the client.
Below are OpenSSL API flow sequence:

OPENSSL_init_ssl(0, NULL);
const SSL_METHOD *method = TLS_server_method();
ctx = SSL_CTX_new(method);
SSL_CTX_set_min_proto_version(ctx, TLS1_3_VERSION);
SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION);
SSL_CTX_use_certificate_file(ctx, sslCertFile, SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, sslPvtkeyFile, SSL_FILETYPE_PEM);
SSL_CTX_check_private_key(ctx);
SSL* ssl = SSL_new(ctx);
SSL_set_fd(ssl, conn_fd);
int ret = SSL_accept(ssl);
Packet Transmission: The client sends a packet using the SSL_write 
function, with the destination process as one byte of data to prepare the 
arguement to create new process with exec().
      OpenSSL API: SSL_write()
Packet Reception: The server daemon reads the packet using the SSL_read 
function.
      OpenSSL API: SSL_read()
Argument Preparation: The server prepares the arguments for running the 
MAPPER program.
The server daemon initiates a fork() system call. In the child process, it 
executes the mapper.exe program using the execvp() system call, passing the 
site letter and socket ID as arguments. The execvp() system call is 
structured as follows:

execvp(execp, args);
execp = "/usr/bin/<our_product binary>";
After execution, the socket connection is closed, and the daemon resumes 
listening for new connections.
New server Process: The new server process is created. call SSL_new, 
SSL_ctx, getting socket-id from daemon as arguement. Then use SSL_set_fd() 
and then SSL_read and SSL_write.
Logon Packet: The client sends a logon packet to the new BIS process which 
will start real work.
Logon Response: The new server process receives the logon packet, processes 
it, and sends a logon response back to the client. Upon successful logon, 
the client and the server process proceed with further data communication.
We are facing an issue where SSL communication between the client and the 
new BIS server program fails after the execvp() system call. While we are 
able to establish the TLS connection between the client and the server 
daemon and successfully read the packet at the daemon level, any TLS 
communication following the execution of the execvp() system call is 
unsuccessful.


The task of our daemon process is relatively simple; it reads once only a 
single byte of non sessitive data, accompanied by a  our defined header for 
the destination site, prior to invoking execvp to prepare the arguments. 
After the execvp call, the new server process handles the actual 
operations, including attaching to its own shared memory segment, managing 
its own memory, accessing all global variables and data, handling its 
session and state management, and reading and writing large reports in 
chunks. This design has been in place since the beginning, and I believe 
that introducing any significant changes could lead to increased complexity 
when managing parent or new shared memory.

Could you please guide us on how to properly establish a new server 
connection after the execvp() system call and ensure that the TLS state is 
maintained across processes? We are currently blocked from proceeding and 
would greatly appreciate any insights or recommendations to resolve this 
issue.

We look forward to your guidance.

Regards,
Siddharth

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion on the web visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/9d516272-9b49-4e24-86c3-bf710466f0afn%40openssl.org.