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@xxxxxxxxxxx.
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.
