| 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@xxxxxx
// "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@xxxxxx> 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@xxxxxx
// "One if by land, two if by sea, three if by the Internet."
On Aug 10, 2023, at 10:49 AM, Tomas Mraz <tomas@xxxxxxxxxxx> wrote:
I assume, if these server processes work in sequence, i.e. one does itswork and only then it hands over the processing to the second processit should be possible to do it actually.You would use two separate SSL connections over the same socket - thatis possible. You could also use the SSL_SESSION object from the firstSSL connection within the second process to avoid another fullhandshake as SSL_SESSIONs can be serialized.The first SSL connection must be cleanly terminated by the client/firstserver before you can proceed establishing the second SSL connection.Tomas MrazOn 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
|
