|
Hi Viktor,
Thanks for your response.
Openssl documentation explicitly says "SSL_set_session() is only useful for TLS/SSL clients" while we are transferring the session on the server side from one process to the another. Do you still think that using the session on the server side can prevent us from duplicating the key agreement phase? Best regards | Viele Grüße
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. From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of Viktor Dukhovni <openssl-users@xxxxxxxxxxxx>
Sent: Thursday, August 10, 2023 5:02 PM To: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> Subject: Re: Moving SSL connections between processes (was: Question) > On 10 Aug 2023, at 10:49 am, Tomas Mraz <tomas@xxxxxxxxxxx> 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. Or derive an explicit (non-resumption) PSK over the first connection, and require its use in the second. A sort of authenticated mandatory resumption that "channel-binds" the two handshakes. > The first SSL connection must be cleanly terminated by the client/first > server before you can proceed establishing the second SSL connection. Right, and the underlying second can be moved via file-descriptor passing after the full two-way TLS shutdown. Without channel binding the two SSL handshakes, in principle an MiTM could take over the TCP connection right after the bidectional shutdown, and perform a handshake that "takes over" the rest of the communication. The second SSL handshake still needs some sort of authentication or channel-binding. Of course this does mean that the client has to expect and participate in the connection transfer. -- Viktor. |
