Re: Question

[Todd Short via openssl-users <openssl-users@xxxxxxxxxxx>]

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.

Attachment: signature.asc
Description: Message signed with OpenPGP