stunnel warning: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number
Hi, Taking this opportunity to ask a question on the mentioned warning. In our stunnel setup (stunnel server in a Docker container on Linux, version 5.68 and windows clients on version 5.73, no certificate verification) I am seeing every minute the following lines in stunnel.log on the server side: 2025.01.20 04:12:27 LOG5[0]: Service [siptest] accepted connection from 172.20.23.1:46658 2025.01.20 04:12:27 LOG3[0]: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number 2025.01.20 04:12:27 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket This is every minute, so 04:13:27 again, etc. The warning is there already shortly after container restart without active connections to our SIP devices. I only see it recently. And changing the server/client config with sslVersionMin = TLSv1.2 and sslVersionMax = TLSv1.3 did not resolve it. Since it comes back every minute, I was thinking in the direction of keepalive settings. But do keep alives need encryption? Probably not. Is this just an innocent bug in the stunnel code or could I still do something in my configuration to clear the warn? Thank you for your attention. Marcel de Rooy Rijksmuseum Netherlands xxx
Hi Marcel, SSL/TLS expects a protocol version number in the initial Client Hello message. If something attempts to connect to a TLS-enabled service using a different protocol, the OpenSSL |SSL_accept()| function often returns the “wrong version number” error. It is difficult for OpenSSL or stunnel to determine whether the attempt is innocent or malicious. An interrogation of the people responsible for initiating the connection is probably in order. Have you investigated your 172.20.23.1 machine? Could it be a port scanner or something else that connects to your stunnel every minute? If 172.20.23.1 is a SNAT rule on your router, invalid connection attempts from the Internet are quite common. Best regards, Mike On 1/20/25 3:01 PM, Marcel de Rooy via stunnel-users wrote:
Hi,
Taking this opportunity to ask a question on the mentioned warning.
In our stunnel setup (stunnel server in a Docker container on Linux, version 5.68 and windows clients on version 5.73, no certificate verification) I am seeing every minute the following lines in stunnel.log on the server side:
2025.01.20 04:12:27 LOG5[0]: Service [siptest] accepted connection from 172.20.23.1:46658
2025.01.20 04:12:27 LOG3[0]: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number
2025.01.20 04:12:27 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
This is every minute, so 04:13:27 again, etc. The warning is there already shortly after container restart without active connections to our SIP devices.
I only see it recently. And changing the server/client config with sslVersionMin = TLSv1.2 and sslVersionMax = TLSv1.3 did not resolve it.
Since it comes back every minute, I was thinking in the direction of keepalive settings. But do keep alives need encryption? Probably not.
Is this just an innocent bug in the stunnel code or could I still do something in my configuration to clear the warn?
Thank you for your attention.
Marcel de Rooy
Rijksmuseum Netherlands
<https://www.instagram.com/rijksmuseum/>
x
<https://www.facebook.com/rijksmuseum>
x
<https://www.linkedin.com/company/rijksmuseum/>
x
Rijksmuseum.nl <https://www.rijksmuseum.nl/nl>
_______________________________________________ stunnel-users mailing list [email protected] To unsubscribe send an email [email protected]
Thanks Mike. The attempts do not seem to come from outside since I am filtering that traffic (tcp stream via nginx). The 23.1 address is the docker gateway of the network where the stunnel container lives. So I think that we must look for an internal suspect. Will still be testing a few things and report back. xxx ________________________________ Van: Michał Trojnara via stunnel-users <[email protected]> Verzonden: maandag 20 januari 2025 17:01 Aan: [email protected] <[email protected]> Onderwerp: [stunnel-users] Re: stunnel warning: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number U ontvangt niet vaak e-mail van [email protected]. Ontdek waarom dit belangrijk is<https://aka.ms/LearnAboutSenderIdentification> Hi Marcel, SSL/TLS expects a protocol version number in the initial Client Hello message. If something attempts to connect to a TLS-enabled service using a different protocol, the OpenSSL SSL_accept() function often returns the “wrong version number” error. It is difficult for OpenSSL or stunnel to determine whether the attempt is innocent or malicious. An interrogation of the people responsible for initiating the connection is probably in order. Have you investigated your 172.20.23.1 machine? Could it be a port scanner or something else that connects to your stunnel every minute? If 172.20.23.1 is a SNAT rule on your router, invalid connection attempts from the Internet are quite common. Best regards, Mike On 1/20/25 3:01 PM, Marcel de Rooy via stunnel-users wrote: Hi, Taking this opportunity to ask a question on the mentioned warning. In our stunnel setup (stunnel server in a Docker container on Linux, version 5.68 and windows clients on version 5.73, no certificate verification) I am seeing every minute the following lines in stunnel.log on the server side: 2025.01.20 04:12:27 LOG5[0]: Service [siptest] accepted connection from 172.20.23.1:46658 2025.01.20 04:12:27 LOG3[0]: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number 2025.01.20 04:12:27 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket This is every minute, so 04:13:27 again, etc. The warning is there already shortly after container restart without active connections to our SIP devices. I only see it recently. And changing the server/client config with sslVersionMin = TLSv1.2 and sslVersionMax = TLSv1.3 did not resolve it. Since it comes back every minute, I was thinking in the direction of keepalive settings. But do keep alives need encryption? Probably not. Is this just an innocent bug in the stunnel code or could I still do something in my configuration to clear the warn? Thank you for your attention. Marcel de Rooy Rijksmuseum Netherlands [cid:[email protected]]<https://www.instagram.com/rijksmuseum/> x [cid:[email protected]]<https://www.facebook.com/rijksmuseum> x [cid:[email protected]]<https://www.linkedin.com/company/rijksmuseum/> x [cid:[email protected]]<https://x.com/rijksmuseum> [Rijksmuseum.nl]<https://www.rijksmuseum.nl/nl> _______________________________________________ stunnel-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
On Tue, Jan 21, 2025 at 03:24:36PM +0000, Marcel de Rooy via stunnel-users wrote:
Thanks Mike. The attempts do not seem to come from outside since I am filtering that traffic (tcp stream via nginx). The 23.1 address is the docker gateway of the network where the stunnel container lives. So I think that we must look for an internal suspect. Will still be testing a few things and report back.
If these connection attempts really do come at regular intervals, I would suggest looking for some monitoring system that tries to make sure the stunnel server is up and running. Unfortunately, as you have found out, connecting and then immediately disconnecting is NOT a good way to check whether an stunnel service is up :) The only way to really check that would be to: - know the purpose of the tunnels maintained by the stunnel service - make sure there is a way to run a monitoring check based on that purpose without making any changes to existing data, "just checking" - if there is indeed such a way, then change the monitoring check to actually wait for stunnel to establish the tunnel and then send/receive some data along that tunnel to make sure that both the tunnel itself and the service behind the tunnel are okay As I have written in previous e-mails, trying to check whether a host merely accepts a TCP connection on a particular port is not really a good health check for many reasons, the most trivial one being that it may be possible that the connection will be accepted by the kernel, but for many reasons (overloaded system, a bug in stunnel, many others) stunnel itself may not be able to process it... so the only way to check is to make sure the tunnel is established and data flows through it correctly. G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Thanks, Peter. That is clear. Finally I discovered that it was no health check or so but still (unexpectedly) one of our devices trying to setup a connection with wrong settings. Thanks for your prompt responses. Marcel xxx ________________________________ Van: Peter Pentchev Verzonden: Woensdag, 22 Januari, 2025 17:59 Aan: Marcel de Rooy CC: [email protected] Onderwerp: Re: [stunnel-users] Re: stunnel warning: SSL_accept: ../ssl/record/ssl3_record.c:354: error:0A00010B:SSL routines::wrong version number On Tue, Jan 21, 2025 at 03:24:36PM +0000, Marcel de Rooy via stunnel-users wrote:
Thanks Mike. The attempts do not seem to come from outside since I am filtering that traffic (tcp stream via nginx). The 23.1 address is the docker gateway of the network where the stunnel container lives. So I think that we must look for an internal suspect. Will still be testing a few things and report back.
If these connection attempts really do come at regular intervals, I would suggest looking for some monitoring system that tries to make sure the stunnel server is up and running. Unfortunately, as you have found out, connecting and then immediately disconnecting is NOT a good way to check whether an stunnel service is up :) The only way to really check that would be to: - know the purpose of the tunnels maintained by the stunnel service - make sure there is a way to run a monitoring check based on that purpose without making any changes to existing data, "just checking" - if there is indeed such a way, then change the monitoring check to actually wait for stunnel to establish the tunnel and then send/receive some data along that tunnel to make sure that both the tunnel itself and the service behind the tunnel are okay As I have written in previous e-mails, trying to check whether a host merely accepts a TCP connection on a particular port is not really a good health check for many reasons, the most trivial one being that it may be possible that the connection will be accepted by the kernel, but for many reasons (overloaded system, a bug in stunnel, many others) stunnel itself may not be able to process it... so the only way to check is to make sure the tunnel is established and data flows through it correctly. G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
participants (3)
-
Marcel de Rooy -
Michał Trojnara -
Peter Pentchev