Question

[Todd Short]

Of course, this all might be moot with kTLS… The handshake could occur in process 1, and then the socket is handed over process 2.

AFAIR, the bulk decryption/encryption happens in the kernel, so process 2 would just need to read/write the socket as anything else using kTLS does, so this might require some code to handle alerts, handshake-messages (which ought to be ignored), etc. But it might be do-able.

(My implementation didn’t use kTLS because we needed ciphers and SSL/TLS versions that were not supported by kTLS.)
--
-Todd Short
// todd.short at me.com
// "One if by land, two if by sea, three if by the Internet."

> On Aug 10, 2023, at 11:13 AM, Todd Short <todd.short at me.com> wrote:
> 
> I think the crux here is “terminated”. They don’t want to terminate the first connection nor establish a second SSL connection based on question (3).
> 
> This is another way to do it, assuming that the connections can be terminated and resumed, but it did not appear that was the question.
> 
> AFAICT, they were asking if two SSL connections could be on the same socket simultaneously in question (2), based on question (1).
> --
> -Todd Short
> // todd.short at me.com
> // "One if by land, two if by sea, three if by the Internet."
> 
>> On Aug 10, 2023, at 10:49 AM, Tomas Mraz <tomas at openssl.org> wrote:
>> 
>> 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 at me.com
>>> // "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 at actian.com> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230810/b051ccc9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230810/b051ccc9/attachment-0001.sig>