I assume, if these server processes work in sequence, i.e. one does its work and only then it hands over the processing to the second process it should be possible to do it actually. You would use two separate SSL connections over the same socket - that is possible. You could also use the SSL_SESSION object from the first SSL connection within the second process to avoid another full handshake as SSL_SESSIONs can be serialized. The first SSL connection must be cleanly terminated by the client/first server before you can proceed establishing the second SSL connection. Tomas Mraz On Thu, 2023-08-10 at 10:25 -0400, Todd Short via openssl-users wrote: > Short answer: No, the OpenSSL library is not able to do this AS-IS. > > Long answer: > > 1) This would require serialization/deserialization of the SSL > structure, which is opaque. The process is similar to how the > SSL_SESSION is serialized in ssl/ssl_asn1.c, but is much more > complicated. It requires internal knowledge of the handshake process > and the SSL data structure. It can be done in a separate source file > (i.e. there’s very little integration required with the rest of the > system), but it’s fragile. I have done this in another job, and it > took a while (months) to get right. > > 2) This would require both processes to have the exact same data, > including private keys and even the random data stream. The second > process could glean the connection, gathering most of this data, but > it may still require additional information from the first process, > which may not be exportable. (But see 3 below.) > > 3) I believe the symmetric keys can be exported, but I’m not sure it > can be easily imported into OpenSSL. Even so, there’s A LOT more > state involved, especially when transferring the connection between > processes in the middle of the connection. This is trying to minimize > the amount of data from 1, which is difficult. The exported keys are > meant for tools that can decrypt a connection given the WHOLE data > stream (and symmetric keys), but they are building the state as they > process the data stream (e.g. Wireshark). > > The easiest out-of-the-box solution (i.e. no changes to OpenSSL or > reliance on internal data structures) is to continue to decrypt in > process 1, and use another encrypted back-haul connection from > process 1 to process 2. Alternatively, another process (process 0) > would accept and decrypt the connection and create separate encrypted > back-haul connections to process 1 and process 2; depending on the > data and algorithm requirements. > > If the goal here is to have process 1 be the protected public/private > keystore from the data-processing process 2, then you might want to > consider using your own Provider in process 2 to send data to process > 1 for public/private key operations; not dissimilar to a SmartCard or > other crypto hardware that stores keys. Option 2 above would not be > viable here, as it would require both process 1 and 2 to have the > public/private keypair. > > -- > -Todd Short > // todd.short@xxxxxx > // "One if by land, two if by sea, three if by the Internet." > > > On Aug 9, 2023, at 8:39 AM, Mohammad Zolfaghari > > <mohammad.zolfaghari@xxxxxxxxxx> wrote: > > > > We are going to use openssl library in our product. A Client/Server > > communication that should be encrypted with openssl but there are > > two processes on the server side. Having done the first process, > > the socket handle will be handed over to the second process and it > > is needed for both processes to communicate encrypted. So, we have > > the following questions and would be appreciated if you answer: > > 1. It seems that ssl object is not assumed to be shared among > > processes by IPC mechanisms. Is there a way for doing so? > > 2. If not, is it possible to start two ssl channels on the same > > underlying socket, one for each process to work on? > > 3. Is it possible to export the agreed key (symmetric key) from > > one ssl object and import it into another ssl object (on different > > process) to avoid re-establishing the key agreement phase multiple > > times? > > > > > > Best regards | Viele Grüße > > > > <Outlook-nlqdmhkm.png> Mohammad Zolfaghari Software Engineer > > Actian, A Division of HCLSoftware M +49 162 27 88 158 > > www.actian.com <Outlook-synbku5o.png> > > > > GESELLSCHAFTSANGABEN: Actian Germany GmbH | Sitz der Gesellschaft: > > Halenreie 42, 22359 Hamburg | Geschäftsführung: Stephen Padgett, > > Marc Monahan | Handelsregister: Amtsgericht Hamburg | HRB 135991 | > > USt-IdNr: DE252449897 > > CONFIDENTIAL: This email and any files transmitted with it are > > confidential and intended solely for the use of the individual or > > entity to whom they are addressed. If you have received this email > > in error, please notify the system manager. This message contains > > confidential information and is intended only for the individual > > named. If you are not the named addressee you should not > > disseminate, distribute or copy this e-mail. Please notify the > > sender immediately by e-mail if you have received this e-mail by > > mistake and delete this e-mail from your system. If you are not the > > intended recipient you are notified that disclosing, copying, > > distributing or taking any action in reliance on the contents of > > this information is strictly prohibited. > -- Tomáš Mráz, OpenSSL
