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
Thanks in advance,
Mikhail