Hi folks,

is there any chance to grasp why such a line - "No peer temporary key received" - is logged immediately after successful negotiation? It does not look harmful but I cannot understand how ECDHE can do without the ephemeral key.

2023.02.17 20:33:41 LOG6[4]: TLS accepted: new session negotiated 2023.02.17 20:33:41 LOG6[4]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) 2023.02.17 20:33:41 LOG6[4]: No peer temporary key received 2023.02.17 20:33:41 LOG7[4]: Compression: null, expansion: null 2023.02.17 20:33:41 LOG6[4]: s_connect: connecting 127.0.0.1:9000 2023.02.17 20:33:41 LOG7[4]: s_connect: s_poll_wait 127.0.0.1:9000: waiting 10 seconds 2023.02.17 20:33:41 LOG7[4]: FD=524 ifds=--- ofds=r-- 2023.02.17 20:33:41 LOG7[4]: FD=540 ifds=rwx ofds=--- 2023.02.17 20:33:41 LOG5[4]: s_connect: connected 127.0.0.1:9000

The above is logged by Stunnel 5.67/5.68; whereas Stunnel 5.66 logs the very same moments differently: it says "SSL_get_peer_tmp_key: Peer suddenly disconnected" (but this can hardly be true).

2023.02.17 20:27:15 LOG6[4]: TLS accepted: new session negotiated

2023.02.17 20:27:15 LOG6[4]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)

2023.02.17 20:27:15 LOG3[4]: SSL_get_peer_tmp_key: Peer suddenly disconnected

2023.02.17 20:27:15 LOG7[4]: Compression: null, expansion: null

2023.02.17 20:27:15 LOG6[4]: s_connect: connecting 127.0.0.1:9000

2023.02.17 20:27:15 LOG7[4]: s_connect: s_poll_wait 127.0.0.1:9000: waiting 10 seconds

2023.02.17 20:27:15 LOG7[4]: FD=512 ifds=--- ofds=r--

2023.02.17 20:27:15 LOG7[4]: FD=528 ifds=rwx ofds=---

2023.02.17 20:27:15 LOG5[4]: s_connect: connected 127.0.0.1:9000

Mikhail