As shown in Figure 1, this type of application is forked by a daemon application, such as INETD, to handle a single passive connection to a socket that the daemon is listening on. The daemon invokes the bind(), listen(), and accept() services on the parent socket. It then forks a new process to handle each child connection, optionally changes the new process to a different identity, and optionally execs a configured server application. The server application reads and writes data on the child connection.
Some server applications support a second parallel connection with the client. This is often an active connection, established by connecting back to an ephemeral port opened by the client at the client's IP address. For a description of an alternative method of mapping policy for these special cases, see Secondary connection application model.
Many server applications allow the client to log in with a user ID on the server system. Some server applications change the security environment of the server process to the client-specified identity prior to accessing resources on behalf of the client. Other server applications set up another communications path (pseudo terminal, named pipe, UNIX domain socket, and so on) and then fork an additional client process. The server changes the security environment in this client process to the client-specified identity, and then execs a client-specified program or login shell.
The initial child connection transferred by the daemon to the server process, and any additional connections established by the server process, perform TLS handshaking as the server, optionally requiring client authentication. Each forked server process runs under the same user ID. All of the server processes forked to handle child connections of the same parent connection should be able to share the session ID cache in the SSL environment. The server processes can use a shared key ring with a site certificate or a private key ring with a server certificate. The key ring used must contain the chain of root certificates needed to validate the site or server certificate it presents to the client. If the server requires client authentication, it must also have any other root certificates necessary to validate client certificates presented on its key ring.
Any client process forked by the server process is treated as a new application by AT-TLS. New connections established will not share an SSL environment with the server process that created them.