Fwd: Re: Question

udhayakumar udhayakumar at fatpipeinc.com
Fri Aug 11 03:45:45 UTC 2023


hi ,

    yes we can able to do multiple process once process doing connection 
establishment and another process to taker over and processing will able 
to do you can keep the openssl  object and share to child or qeue to 
another thread able do!  i did in very past in threads i did  Design is 
below if want you can use same Design


  * Listener – thread that performs bind() and listen() calls and waits
    for incoming conncetions. Then new connection arrives, this thread
    can do accept() on listening socket an send accepted connection
    socket to one   of the I/O-workers.
  * I/O-Worker(s) – one or more threads to receive connections from
    listener and to add them to epoll. Main loop of the generic
    I/O-worker looks like last step of epoll using pattern described above.
  * Data Processing Worker(s) – one or more threads to receive data from
    and send data to I/O-workers and to perform data processing.

/udhaya kumar.


On 10/08/23 9:27 pm, Todd Short via openssl-users wrote:
> 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/20230811/6e2104fe/attachment-0001.htm>


More information about the openssl-users mailing list