Stunnel connection issue?
I've been trying to get Stunnel to work for some time now. I have avoided using the mail list - but I see no recourse now. I think I've tried just about every setting I could find. I appear to be getting a connection issue - but as you will see the log just doesn't indicate clearly what is going on. The behavior is my client is failing to get a connection through Stunnel to my backend. The log appears to be closing a socket (but can't tell which one frontend or backend). Nothing wrong happens up until a client connects - 443 binds fine and later a connection to my backend 554 appears to connect find. If someone/anyone can help direct me to how to trouble shoot this better I would greatly appreciate it. As you will see in the log - the client attempts twice to get through. An excerpt of my log and the conf is below. /etc/stunnel.conf: socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 output = /var/log/stunnel.log debug=7 [rtsp] cert = /etc/stunnel/stunnel.pem accept=192.168.112.16:443 connect=192.168.112.16:554 TIMEOUTclose = 0 TIMEOUTbusy = 5 TIMEOUTidle = 30 delay = yes sslVersion = TLSv1.2 /var/log/stunnel.log: 2018.07.05 05:31:01 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.197:43869 2018.07.05 05:31:01 LOG7[5]: Service [rtsp] started 2018.07.05 05:31:01 LOG7[5]: Setting local socket options (FD=3) 2018.07.05 05:31:01 LOG7[5]: Option TCP_NODELAY set on local socket 2018.07.05 05:31:01 LOG5[5]: Service [rtsp] accepted connection from 192.168.112.197:43869 2018.07.05 05:31:01 LOG6[5]: Peer certificate not required 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): before SSL initialization 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): before SSL initialization 2018.07.05 05:31:01 LOG7[5]: SNI: no virtual services defined 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read client hello 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server hello 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write certificate 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write key exchange 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read client key exchange 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read change cipher spec 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read finished 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write change cipher spec 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write finished 2018.07.05 05:31:01 LOG7[5]: New session callback 2018.07.05 05:31:01 LOG6[5]: No peer certificate received 2018.07.05 05:31:01 LOG7[5]: 6 server accept(s) requested 2018.07.05 05:31:01 LOG7[5]: 3 server accept(s) succeeded 2018.07.05 05:31:01 LOG7[5]: 0 server renegotiation(s) requested 2018.07.05 05:31:01 LOG7[5]: 0 session reuse(s) 2018.07.05 05:31:01 LOG7[5]: 3 internal session cache item(s) 2018.07.05 05:31:01 LOG7[5]: 0 internal session cache fill-up(s) 2018.07.05 05:31:01 LOG7[5]: 0 internal session cache miss(es) 2018.07.05 05:31:01 LOG7[5]: 0 external session cache hit(s) 2018.07.05 05:31:01 LOG7[5]: 0 expired session(s) retrieved 2018.07.05 05:31:01 LOG6[5]: TLS accepted: new session negotiated 2018.07.05 05:31:01 LOG6[5]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) 2018.07.05 05:31:01 LOG7[5]: Compression: null, expansion: null 2018.07.05 05:31:01 LOG6[5]: s_connect: connecting 192.168.112.16:554 2018.07.05 05:31:01 LOG7[5]: s_connect: s_poll_wait 192.168.112.16:554: waiting 10 seconds 2018.07.05 05:31:01 LOG5[5]: s_connect: connected 192.168.112.16:554 2018.07.05 05:31:01 LOG6[5]: persistence: 192.168.112.16:554 cached 2018.07.05 05:31:01 LOG5[5]: Service [rtsp] connected remote server from 192.168.112.16:58594 2018.07.05 05:31:01 LOG7[5]: Setting remote socket options (FD=9) 2018.07.05 05:31:01 LOG7[5]: Option TCP_NODELAY set on remote socket 2018.07.05 05:31:01 LOG7[5]: Remote descriptor (FD=9) initialized 2018.07.05 05:31:02 LOG6[5]: TLS socket closed (SSL_read) 2018.07.05 05:31:02 LOG7[5]: Sent socket write shutdown 2018.07.05 05:31:02 LOG5[5]: Connection closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2018.07.05 05:31:02 LOG7[5]: Remote descriptor (FD=9) closed 2018.07.05 05:31:02 LOG7[5]: Local descriptor (FD=3) closed 2018.07.05 05:31:02 LOG7[5]: Service [rtsp] finished (0 left) 2018.07.05 05:31:02 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:02 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:02 LOG7[main]: FD=7 events=0x2001 revents=0x1 2018.07.05 05:31:02 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.197:43870 2018.07.05 05:31:02 LOG7[6]: Service [rtsp] started 2018.07.05 05:31:02 LOG7[6]: Setting local socket options (FD=3) 2018.07.05 05:31:02 LOG7[6]: Option TCP_NODELAY set on local socket 2018.07.05 05:31:02 LOG5[6]: Service [rtsp] accepted connection from 192.168.112.197:43870 2018.07.05 05:31:02 LOG6[6]: Peer certificate not required 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): before SSL initialization 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): before SSL initialization 2018.07.05 05:31:02 LOG7[6]: SNI: no virtual services defined 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read client hello 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server hello 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write certificate 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write key exchange 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read client key exchange 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read change cipher spec 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read finished 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write change cipher spec 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write finished 2018.07.05 05:31:02 LOG7[6]: New session callback 2018.07.05 05:31:02 LOG6[6]: No peer certificate received 2018.07.05 05:31:02 LOG7[6]: 7 server accept(s) requested 2018.07.05 05:31:02 LOG7[6]: 4 server accept(s) succeeded 2018.07.05 05:31:02 LOG7[6]: 0 server renegotiation(s) requested 2018.07.05 05:31:02 LOG7[6]: 0 session reuse(s) 2018.07.05 05:31:02 LOG7[6]: 4 internal session cache item(s) 2018.07.05 05:31:02 LOG7[6]: 0 internal session cache fill-up(s) 2018.07.05 05:31:02 LOG7[6]: 0 internal session cache miss(es) 2018.07.05 05:31:02 LOG7[6]: 0 external session cache hit(s) 2018.07.05 05:31:02 LOG7[6]: 0 expired session(s) retrieved 2018.07.05 05:31:02 LOG6[6]: TLS accepted: new session negotiated 2018.07.05 05:31:02 LOG6[6]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) 2018.07.05 05:31:02 LOG7[6]: Compression: null, expansion: null 2018.07.05 05:31:02 LOG6[6]: s_connect: connecting 192.168.112.16:554 2018.07.05 05:31:02 LOG7[6]: s_connect: s_poll_wait 192.168.112.16:554: waiting 10 seconds 2018.07.05 05:31:02 LOG5[6]: s_connect: connected 192.168.112.16:554 2018.07.05 05:31:02 LOG6[6]: persistence: 192.168.112.16:554 cached 2018.07.05 05:31:02 LOG5[6]: Service [rtsp] connected remote server from 192.168.112.16:58596 2018.07.05 05:31:02 LOG7[6]: Setting remote socket options (FD=9) 2018.07.05 05:31:02 LOG7[6]: Option TCP_NODELAY set on remote socket 2018.07.05 05:31:02 LOG7[6]: Remote descriptor (FD=9) initialized 2018.07.05 05:31:02 LOG6[6]: TLS socket closed (SSL_read) 2018.07.05 05:31:02 LOG7[6]: Sent socket write shutdown 2018.07.05 05:31:02 LOG5[6]: Connection closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2018.07.05 05:31:02 LOG7[6]: Remote descriptor (FD=9) closed 2018.07.05 05:31:02 LOG7[6]: Local descriptor (FD=3) closed 2018.07.05 05:31:02 LOG7[6]: Service [rtsp] finished (0 left) 2018.07.05 05:31:05 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:05 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:05 LOG7[main]: FD=7 events=0x2001 revents=0x1
Hi, IMO it would be good to take a look at some debug backend logs. Regards, Flo On Thu, Jul 5, 2018 at 11:58 AM, Spies, Will <Will_Spies@comcast.com> wrote:
I’ve been trying to get Stunnel to work for some time now. I have avoided using the mail list – but I see no recourse now. I think I’ve tried just about every setting I could find. I appear to be getting a connection issue – but as you will see the log just doesn’t indicate clearly what is going on. The behavior is my client is failing to get a connection through Stunnel to my backend. The log appears to be closing a socket (but can’t tell which one frontend or backend). Nothing wrong happens up until a client connects – 443 binds fine and later a connection to my backend 554 appears to connect find. If someone/anyone can help direct me to how to trouble shoot this better I would greatly appreciate it. As you will see in the log – the client attempts twice to get through. An excerpt of my log and the conf is below.
/etc/stunnel.conf:
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
output = /var/log/stunnel.log
debug=7
[rtsp]
cert = /etc/stunnel/stunnel.pem
accept=192.168.112.16:443
connect=192.168.112.16:554
TIMEOUTclose = 0
TIMEOUTbusy = 5
TIMEOUTidle = 30
delay = yes
sslVersion = TLSv1.2
/var/log/stunnel.log:
2018.07.05 05:31:01 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.197:43869
2018.07.05 05:31:01 LOG7[5]: Service [rtsp] started
2018.07.05 05:31:01 LOG7[5]: Setting local socket options (FD=3)
2018.07.05 05:31:01 LOG7[5]: Option TCP_NODELAY set on local socket
2018.07.05 05:31:01 LOG5[5]: Service [rtsp] accepted connection from 192.168.112.197:43869
2018.07.05 05:31:01 LOG6[5]: Peer certificate not required
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): before SSL initialization
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): before SSL initialization
2018.07.05 05:31:01 LOG7[5]: SNI: no virtual services defined
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read client hello
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server hello
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write certificate
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write key exchange
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server done
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server done
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read client key exchange
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read change cipher spec
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read finished
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write change cipher spec
2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write finished
2018.07.05 05:31:01 LOG7[5]: New session callback
2018.07.05 05:31:01 LOG6[5]: No peer certificate received
2018.07.05 05:31:01 LOG7[5]: 6 server accept(s) requested
2018.07.05 05:31:01 LOG7[5]: 3 server accept(s) succeeded
2018.07.05 05:31:01 LOG7[5]: 0 server renegotiation(s) requested
2018.07.05 05:31:01 LOG7[5]: 0 session reuse(s)
2018.07.05 05:31:01 LOG7[5]: 3 internal session cache item(s)
2018.07.05 05:31:01 LOG7[5]: 0 internal session cache fill-up(s)
2018.07.05 05:31:01 LOG7[5]: 0 internal session cache miss(es)
2018.07.05 05:31:01 LOG7[5]: 0 external session cache hit(s)
2018.07.05 05:31:01 LOG7[5]: 0 expired session(s) retrieved
2018.07.05 05:31:01 LOG6[5]: TLS accepted: new session negotiated
2018.07.05 05:31:01 LOG6[5]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)
2018.07.05 05:31:01 LOG7[5]: Compression: null, expansion: null
2018.07.05 05:31:01 LOG6[5]: s_connect: connecting 192.168.112.16:554
2018.07.05 05:31:01 LOG7[5]: s_connect: s_poll_wait 192.168.112.16:554: waiting 10 seconds
2018.07.05 05:31:01 LOG5[5]: s_connect: connected 192.168.112.16:554
2018.07.05 05:31:01 LOG6[5]: persistence: 192.168.112.16:554 cached
2018.07.05 05:31:01 LOG5[5]: Service [rtsp] connected remote server from 192.168.112.16:58594
2018.07.05 05:31:01 LOG7[5]: Setting remote socket options (FD=9)
2018.07.05 05:31:01 LOG7[5]: Option TCP_NODELAY set on remote socket
2018.07.05 05:31:01 LOG7[5]: Remote descriptor (FD=9) initialized
2018.07.05 05:31:02 LOG6[5]: TLS socket closed (SSL_read)
2018.07.05 05:31:02 LOG7[5]: Sent socket write shutdown
2018.07.05 05:31:02 LOG5[5]: Connection closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
2018.07.05 05:31:02 LOG7[5]: Remote descriptor (FD=9) closed
2018.07.05 05:31:02 LOG7[5]: Local descriptor (FD=3) closed
2018.07.05 05:31:02 LOG7[5]: Service [rtsp] finished (0 left)
2018.07.05 05:31:02 LOG7[main]: Found 1 ready file descriptor(s)
2018.07.05 05:31:02 LOG7[main]: FD=4 events=0x2001 revents=0x0
2018.07.05 05:31:02 LOG7[main]: FD=7 events=0x2001 revents=0x1
2018.07.05 05:31:02 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.197:43870
2018.07.05 05:31:02 LOG7[6]: Service [rtsp] started
2018.07.05 05:31:02 LOG7[6]: Setting local socket options (FD=3)
2018.07.05 05:31:02 LOG7[6]: Option TCP_NODELAY set on local socket
2018.07.05 05:31:02 LOG5[6]: Service [rtsp] accepted connection from 192.168.112.197:43870
2018.07.05 05:31:02 LOG6[6]: Peer certificate not required
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): before SSL initialization
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): before SSL initialization
2018.07.05 05:31:02 LOG7[6]: SNI: no virtual services defined
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read client hello
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server hello
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write certificate
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write key exchange
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server done
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server done
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read client key exchange
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read change cipher spec
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read finished
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write change cipher spec
2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write finished
2018.07.05 05:31:02 LOG7[6]: New session callback
2018.07.05 05:31:02 LOG6[6]: No peer certificate received
2018.07.05 05:31:02 LOG7[6]: 7 server accept(s) requested
2018.07.05 05:31:02 LOG7[6]: 4 server accept(s) succeeded
2018.07.05 05:31:02 LOG7[6]: 0 server renegotiation(s) requested
2018.07.05 05:31:02 LOG7[6]: 0 session reuse(s)
2018.07.05 05:31:02 LOG7[6]: 4 internal session cache item(s)
2018.07.05 05:31:02 LOG7[6]: 0 internal session cache fill-up(s)
2018.07.05 05:31:02 LOG7[6]: 0 internal session cache miss(es)
2018.07.05 05:31:02 LOG7[6]: 0 external session cache hit(s)
2018.07.05 05:31:02 LOG7[6]: 0 expired session(s) retrieved
2018.07.05 05:31:02 LOG6[6]: TLS accepted: new session negotiated
2018.07.05 05:31:02 LOG6[6]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption)
2018.07.05 05:31:02 LOG7[6]: Compression: null, expansion: null
2018.07.05 05:31:02 LOG6[6]: s_connect: connecting 192.168.112.16:554
2018.07.05 05:31:02 LOG7[6]: s_connect: s_poll_wait 192.168.112.16:554: waiting 10 seconds
2018.07.05 05:31:02 LOG5[6]: s_connect: connected 192.168.112.16:554
2018.07.05 05:31:02 LOG6[6]: persistence: 192.168.112.16:554 cached
2018.07.05 05:31:02 LOG5[6]: Service [rtsp] connected remote server from 192.168.112.16:58596
2018.07.05 05:31:02 LOG7[6]: Setting remote socket options (FD=9)
2018.07.05 05:31:02 LOG7[6]: Option TCP_NODELAY set on remote socket
2018.07.05 05:31:02 LOG7[6]: Remote descriptor (FD=9) initialized
2018.07.05 05:31:02 LOG6[6]: TLS socket closed (SSL_read)
2018.07.05 05:31:02 LOG7[6]: Sent socket write shutdown
2018.07.05 05:31:02 LOG5[6]: Connection closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
2018.07.05 05:31:02 LOG7[6]: Remote descriptor (FD=9) closed
2018.07.05 05:31:02 LOG7[6]: Local descriptor (FD=3) closed
2018.07.05 05:31:02 LOG7[6]: Service [rtsp] finished (0 left)
2018.07.05 05:31:05 LOG7[main]: Found 1 ready file descriptor(s)
2018.07.05 05:31:05 LOG7[main]: FD=4 events=0x2001 revents=0x0
2018.07.05 05:31:05 LOG7[main]: FD=7 events=0x2001 revents=0x1
_______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
On Thu, Jul 05, 2018 at 01:12:45PM +0200, Flo Rance wrote:
Hi,
IMO it would be good to take a look at some debug backend logs.
As I said in another reply I just sent, it's not the backend, the client closes the secure connection immediately after establishing it. G'luck, Peter -- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
On Thu, Jul 05, 2018 at 09:58:33AM +0000, Spies, Will wrote:
I've been trying to get Stunnel to work for some time now. I have avoided using the mail list - but I see no recourse now. I think I've tried just about every setting I could find. I appear to be getting a connection issue - but as you will see the log just doesn't indicate clearly what is going on. The behavior is my client is failing to get a connection through Stunnel to my backend. The log appears to be closing a socket (but can't tell which one frontend or backend).
Actually the log says "TLS socket closed (SSL_read)", which means that the "read some bytes from the secure socket" operation said "there are no bytes to read, the other side closed the connection", meaning your client, the one that negotiates the TLS connection with stunnel, has closed the connection immediately after stunnel considered it negotiated. The next line in the log, "0 byte(s) sent to TLS, 0 byte(s) sent to socket", says that the client did indeed not even try to send any data over the established secure connection or receive any data from it, it just closed the connection immediately after stunnel thought they had formed a chummy relationship. Is there any way you could get your client program to log verbosely what it is trying to do over the secure connection? Are there any messages on that side? G'luck, Peter -- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Thanks for the quick response. The client is an Echo Show device and there is no log. It is an RTSP connection and my backend (behind Stunnel) is Live555ProxyServer. I read somewhere there is some bug related to MSIE that closed the connection like this and the fix is to use TIMEOUTclose=0 which I did but this did not help. This is the earlier (startup) portion of my log: 2018.07.05 05:30:45 LOG7[ui]: Clients allowed=500 2018.07.05 05:30:45 LOG5[ui]: stunnel 5.48 on x86_64-pc-linux-gnu platform 2018.07.05 05:30:45 LOG5[ui]: Compiled/running with OpenSSL 1.1.0g 2 Nov 2017 2018.07.05 05:30:45 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI 2018.07.05 05:30:45 LOG7[ui]: errno: (*__errno_location ()) 2018.07.05 05:30:45 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2018.07.05 05:30:45 LOG5[ui]: UTF-8 byte order mark not detected 2018.07.05 05:30:45 LOG5[ui]: FIPS mode disabled 2018.07.05 05:30:45 LOG7[ui]: Compression disabled 2018.07.05 05:30:45 LOG7[ui]: No PRNG seeding was required 2018.07.05 05:30:45 LOG6[ui]: Initializing service [rtsp] 2018.07.05 05:30:45 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2018.07.05 05:30:45 LOG7[ui]: TLS options: 0x02004004 (+0x00004000, -0x00000000) 2018.07.05 05:30:45 LOG6[ui]: Loading certificate from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Certificate loaded from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Loading private key from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG4[ui]: Insecure file permissions on /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Private key loaded from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG7[ui]: Private key check succeeded 2018.07.05 05:30:45 LOG7[ui]: ECDH initialization 2018.07.05 05:30:45 LOG7[ui]: ECDH initialized with curve prime256v1 2018.07.05 05:30:45 LOG5[ui]: Configuration successful 2018.07.05 05:30:45 LOG7[ui]: Binding service [rtsp] 2018.07.05 05:30:45 LOG7[ui]: Listening file descriptor created (FD=7) 2018.07.05 05:30:45 LOG7[ui]: Setting accept socket options (FD=7) 2018.07.05 05:30:45 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2018.07.05 05:30:45 LOG6[ui]: Service [rtsp] (FD=7) bound to 192.168.112.16:443 2018.07.05 05:30:45 LOG7[main]: No pid file being created 2018.07.05 05:30:45 LOG7[cron]: Cron thread initialized 2018.07.05 05:31:00 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:00 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:00 LOG7[main]: FD=7 events=0x2001 revents=0x1 2018.07.05 05:31:00 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.194:51692 2018.07.05 05:31:00 LOG7[0]: Service [rtsp] started 2018.07.05 05:31:00 LOG7[0]: Setting local socket options (FD=3) 2018.07.05 05:31:00 LOG7[0]: Option TCP_NODELAY set on local socket 2018.07.05 05:31:00 LOG5[0]: Service [rtsp] accepted connection from 192.168.112.194:51692 2018.07.05 05:31:00 LOG6[0]: Peer certificate not required 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): before SSL initialization 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): before SSL initialization 2018.07.05 05:31:00 LOG7[0]: SNI: no virtual services defined 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS read client hello 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write server hello 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write certificate 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write key exchange 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:00 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:00 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:00 LOG7[main]: FD=7 events=0x2001 revents=0x1 2018.07.05 05:31:00 LOG7[main]: Service [rtsp] accepted (FD=9) from 192.168.112.197:43868 (bottom part in my original email) -----Original Message----- From: Peter Pentchev [mailto:roam@ringlet.net] Sent: Thursday, July 05, 2018 7:18 AM To: Spies, Will <Will_Spies@cable.comcast.com> Cc: stunnel-users@stunnel.org Subject: [EXTERNAL] Re: [stunnel-users] Stunnel connection issue? On Thu, Jul 05, 2018 at 09:58:33AM +0000, Spies, Will wrote:
I've been trying to get Stunnel to work for some time now. I have avoided using the mail list - but I see no recourse now. I think I've tried just about every setting I could find. I appear to be getting a connection issue - but as you will see the log just doesn't indicate clearly what is going on. The behavior is my client is failing to get a connection through Stunnel to my backend. The log appears to be closing a socket (but can't tell which one frontend or backend).
Actually the log says "TLS socket closed (SSL_read)", which means that the "read some bytes from the secure socket" operation said "there are no bytes to read, the other side closed the connection", meaning your client, the one that negotiates the TLS connection with stunnel, has closed the connection immediately after stunnel considered it negotiated. The next line in the log, "0 byte(s) sent to TLS, 0 byte(s) sent to socket", says that the client did indeed not even try to send any data over the established secure connection or receive any data from it, it just closed the connection immediately after stunnel thought they had formed a chummy relationship. Is there any way you could get your client program to log verbosely what it is trying to do over the secure connection? Are there any messages on that side? G'luck, Peter -- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
On Thu, Jul 05, 2018 at 11:41:18AM +0000, Spies, Will wrote:
Thanks for the quick response. The client is an Echo Show device and there is no log. It is an RTSP connection and my backend (behind Stunnel) is Live555ProxyServer. I read somewhere there is some bug related to MSIE that closed the connection like this and the fix is to use TIMEOUTclose=0 which I did but this did not help. This is the earlier (startup) portion of my log:
Hi, Unfortunately, without more information about what the client doesn't like about the established connection, I don't think there is anything more I can help you with :( You *might* try playing with stunnel's cipher settings (OpenSSL options), on the off chance that the client is somewhat confused and offers for negotiation a cipher or something that it later realizes it cannot support... but that would be really weird. G'luck, Peter -- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
So, part of this appeared to be I needed a signed cert from a CA. However, I still have problems. Alexa apparently requires 'Interleaved TCP on port 443 (for both RTP and RTSP). TCP socket encryption on port 443 using TLS 1.2' How do I force Stunnel to only adhere to above? I get the 443 part of course. I am seeing it try SSLv3 in the log and I imagine this is wrong. -----Original Message----- From: Peter Pentchev [mailto:roam@ringlet.net] Sent: Thursday, July 05, 2018 8:47 AM To: Spies, Will <Will_Spies@cable.comcast.com> Cc: stunnel-users@stunnel.org Subject: Re: [EXTERNAL] Re: [stunnel-users] Stunnel connection issue? On Thu, Jul 05, 2018 at 11:41:18AM +0000, Spies, Will wrote:
Thanks for the quick response. The client is an Echo Show device and there is no log. It is an RTSP connection and my backend (behind Stunnel) is Live555ProxyServer. I read somewhere there is some bug related to MSIE that closed the connection like this and the fix is to use TIMEOUTclose=0 which I did but this did not help. This is the earlier (startup) portion of my log:
Hi, Unfortunately, without more information about what the client doesn't like about the established connection, I don't think there is anything more I can help you with :( You *might* try playing with stunnel's cipher settings (OpenSSL options), on the off chance that the client is somewhat confused and offers for negotiation a cipher or something that it later realizes it cannot support... but that would be really weird. G'luck, Peter -- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
You have "options" or "*sslVersion*" to instruct stunnel to use a specific TLS version. https://www.stunnel.org/static/stunnel.html On Mon, Jul 9, 2018 at 12:25 PM, Spies, Will <Will_Spies@comcast.com> wrote:
So, part of this appeared to be I needed a signed cert from a CA. However, I still have problems.
Alexa apparently requires 'Interleaved TCP on port 443 (for both RTP and RTSP). TCP socket encryption on port 443 using TLS 1.2'
How do I force Stunnel to only adhere to above? I get the 443 part of course. I am seeing it try SSLv3 in the log and I imagine this is wrong.
-----Original Message----- From: Peter Pentchev [mailto:roam@ringlet.net] Sent: Thursday, July 05, 2018 8:47 AM To: Spies, Will <Will_Spies@cable.comcast.com> Cc: stunnel-users@stunnel.org Subject: Re: [EXTERNAL] Re: [stunnel-users] Stunnel connection issue?
On Thu, Jul 05, 2018 at 11:41:18AM +0000, Spies, Will wrote:
Thanks for the quick response. The client is an Echo Show device and there is no log. It is an RTSP connection and my backend (behind Stunnel) is Live555ProxyServer. I read somewhere there is some bug related to MSIE that closed the connection like this and the fix is to use TIMEOUTclose=0 which I did but this did not help. This is the earlier (startup) portion of my log:
Hi,
Unfortunately, without more information about what the client doesn't like about the established connection, I don't think there is anything more I can help you with :( You *might* try playing with stunnel's cipher settings (OpenSSL options), on the off chance that the client is somewhat confused and offers for negotiation a cipher or something that it later realizes it cannot support... but that would be really weird.
G'luck, Peter
-- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Will, I was told to ignore the SSLv3 stuff in the log. I have options set to allow only TLS1.2 and still see SSLv3 references in the log. Best regards, Dan -----Original Message----- From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Spies, Will Sent: Monday, July 9, 2018 6:26 AM To: Peter Pentchev <roam@ringlet.net> Cc: stunnel-users@stunnel.org Subject: Re: [stunnel-users] [EXTERNAL] Re: Stunnel connection issue? So, part of this appeared to be I needed a signed cert from a CA. However, I still have problems. Alexa apparently requires 'Interleaved TCP on port 443 (for both RTP and RTSP). TCP socket encryption on port 443 using TLS 1.2' How do I force Stunnel to only adhere to above? I get the 443 part of course. I am seeing it try SSLv3 in the log and I imagine this is wrong. -----Original Message----- From: Peter Pentchev [mailto:roam@ringlet.net] Sent: Thursday, July 05, 2018 8:47 AM To: Spies, Will <Will_Spies@cable.comcast.com> Cc: stunnel-users@stunnel.org Subject: Re: [EXTERNAL] Re: [stunnel-users] Stunnel connection issue? On Thu, Jul 05, 2018 at 11:41:18AM +0000, Spies, Will wrote:
Thanks for the quick response. The client is an Echo Show device and there is no log. It is an RTSP connection and my backend (behind Stunnel) is Live555ProxyServer. I read somewhere there is some bug related to MSIE that closed the connection like this and the fix is to use TIMEOUTclose=0 which I did but this did not help. This is the earlier (startup) portion of my log:
Hi, Unfortunately, without more information about what the client doesn't like about the established connection, I don't think there is anything more I can help you with :( You *might* try playing with stunnel's cipher settings (OpenSSL options), on the off chance that the client is somewhat confused and offers for negotiation a cipher or something that it later realizes it cannot support... but that would be really weird. G'luck, Peter -- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.emdgroup.com/emd/imprint/mail_disclaimer.html to access the German, French, Spanish and Portuguese versions of this disclaimer.
On Mon, 9 Jul 2018 12:26:08 +0000 Daniel Trickett <daniel.trickett@emdmillipore.com> wrote:
Will,
I was told to ignore the SSLv3 stuff in the log. I have options set to allow only TLS1.2 and still see SSLv3 references in the log.
Best regards,
Dan
Hi, in fact, the version can be disclosed from following lines in the log, where is told the cipher used, but not where you usually look: LOG6[1]: TLSv(1-1.1-1.2-1.3-whatever) ciphersuite: (whatever) Regards.
If it helps any, I have the following lines in my config, and no longer see references to SSLv3 sslVersion = TLSv1.2 options = NO_SSLv2 options = NO_SSLv3 Liz Turi Sr. Consultant Massachusetts eHealth Collaborative 860 Winter Street, Waltham, MA 02451 (m) 339-222-6614 (o) 781-907-7204 (f) 781-207-8589 www.maehc.org -----Original Message----- From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Javier Sent: Monday, July 9, 2018 12:55 PM To: stunnel-users@stunnel.org Subject: Re: [stunnel-users] [EXTERNAL] Re: Stunnel connection issue? On Mon, 9 Jul 2018 12:26:08 +0000 Daniel Trickett <daniel.trickett@emdmillipore.com> wrote:
Will,
I was told to ignore the SSLv3 stuff in the log. I have options set to allow only TLS1.2 and still see SSLv3 references in the log.
Best regards,
Dan
Hi, in fact, the version can be disclosed from following lines in the log, where is told the cipher used, but not where you usually look: LOG6[1]: TLSv(1-1.1-1.2-1.3-whatever) ciphersuite: (whatever) Regards. _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users CONFIDENTIALITY NOTICE The information contained in this email transmission is legally privileged and confidential information intended only for the use of the addressee named above. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution or copying of this email transmission is strictly prohibited. If you have received this email transmission in error, please notify us immediately. Thank you.
Hi, Did you try with another type of client to see if the issue is the same ? Flo On Thu, Jul 5, 2018 at 1:41 PM, Spies, Will <Will_Spies@comcast.com> wrote:
Thanks for the quick response. The client is an Echo Show device and there is no log. It is an RTSP connection and my backend (behind Stunnel) is Live555ProxyServer. I read somewhere there is some bug related to MSIE that closed the connection like this and the fix is to use TIMEOUTclose=0 which I did but this did not help. This is the earlier (startup) portion of my log:
2018.07.05 05:30:45 LOG7[ui]: Clients allowed=500 2018.07.05 05:30:45 LOG5[ui]: stunnel 5.48 on x86_64-pc-linux-gnu platform 2018.07.05 05:30:45 LOG5[ui]: Compiled/running with OpenSSL 1.1.0g 2 Nov 2017 2018.07.05 05:30:45 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI 2018.07.05 05:30:45 LOG7[ui]: errno: (*__errno_location ()) 2018.07.05 05:30:45 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2018.07.05 05:30:45 LOG5[ui]: UTF-8 byte order mark not detected 2018.07.05 05:30:45 LOG5[ui]: FIPS mode disabled 2018.07.05 05:30:45 LOG7[ui]: Compression disabled 2018.07.05 05:30:45 LOG7[ui]: No PRNG seeding was required 2018.07.05 05:30:45 LOG6[ui]: Initializing service [rtsp] 2018.07.05 05:30:45 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2018.07.05 05:30:45 LOG7[ui]: TLS options: 0x02004004 (+0x00004000, -0x00000000) 2018.07.05 05:30:45 LOG6[ui]: Loading certificate from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Certificate loaded from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Loading private key from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG4[ui]: Insecure file permissions on /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Private key loaded from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG7[ui]: Private key check succeeded 2018.07.05 05:30:45 LOG7[ui]: ECDH initialization 2018.07.05 05:30:45 LOG7[ui]: ECDH initialized with curve prime256v1 2018.07.05 05:30:45 LOG5[ui]: Configuration successful 2018.07.05 05:30:45 LOG7[ui]: Binding service [rtsp] 2018.07.05 05:30:45 LOG7[ui]: Listening file descriptor created (FD=7) 2018.07.05 05:30:45 LOG7[ui]: Setting accept socket options (FD=7) 2018.07.05 05:30:45 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2018.07.05 05:30:45 LOG6[ui]: Service [rtsp] (FD=7) bound to 192.168.112.16:443 2018.07.05 05:30:45 LOG7[main]: No pid file being created 2018.07.05 05:30:45 LOG7[cron]: Cron thread initialized 2018.07.05 05:31:00 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:00 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:00 LOG7[main]: FD=7 events=0x2001 revents=0x1 2018.07.05 05:31:00 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.194:51692 2018.07.05 05:31:00 LOG7[0]: Service [rtsp] started 2018.07.05 05:31:00 LOG7[0]: Setting local socket options (FD=3) 2018.07.05 05:31:00 LOG7[0]: Option TCP_NODELAY set on local socket 2018.07.05 05:31:00 LOG5[0]: Service [rtsp] accepted connection from 192.168.112.194:51692 2018.07.05 05:31:00 LOG6[0]: Peer certificate not required 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): before SSL initialization 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): before SSL initialization 2018.07.05 05:31:00 LOG7[0]: SNI: no virtual services defined 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS read client hello 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write server hello 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write certificate 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write key exchange 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:00 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:00 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:00 LOG7[main]: FD=7 events=0x2001 revents=0x1 2018.07.05 05:31:00 LOG7[main]: Service [rtsp] accepted (FD=9) from 192.168.112.197:43868 (bottom part in my original email)
-----Original Message----- From: Peter Pentchev [mailto:roam@ringlet.net] Sent: Thursday, July 05, 2018 7:18 AM To: Spies, Will <Will_Spies@cable.comcast.com> Cc: stunnel-users@stunnel.org Subject: [EXTERNAL] Re: [stunnel-users] Stunnel connection issue?
On Thu, Jul 05, 2018 at 09:58:33AM +0000, Spies, Will wrote:
I've been trying to get Stunnel to work for some time now. I have avoided using the mail list - but I see no recourse now. I think I've tried just about every setting I could find. I appear to be getting a connection issue - but as you will see the log just doesn't indicate clearly what is going on. The behavior is my client is failing to get a connection through Stunnel to my backend. The log appears to be closing a socket (but can't tell which one frontend or backend).
Actually the log says "TLS socket closed (SSL_read)", which means that the "read some bytes from the secure socket" operation said "there are no bytes to read, the other side closed the connection", meaning your client, the one that negotiates the TLS connection with stunnel, has closed the connection immediately after stunnel considered it negotiated. The next line in the log, "0 byte(s) sent to TLS, 0 byte(s) sent to socket", says that the client did indeed not even try to send any data over the established secure connection or receive any data from it, it just closed the connection immediately after stunnel thought they had formed a chummy relationship.
Is there any way you could get your client program to log verbosely what it is trying to do over the secure connection? Are there any messages on that side?
G'luck, Peter
-- Peter Pentchev roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
I have tried VLC with different results – I get ‘version too low’ errors with I use VLC rather than what I see when I test the Echo Show device. From: Flo Rance [mailto:trourance@gmail.com] Sent: Thursday, July 05, 2018 9:33 AM To: Spies, Will <Will_Spies@cable.comcast.com> Cc: Peter Pentchev <roam@ringlet.net>; stunnel-users@stunnel.org Subject: Re: [stunnel-users] [EXTERNAL] Re: Stunnel connection issue? Hi, Did you try with another type of client to see if the issue is the same ? Flo On Thu, Jul 5, 2018 at 1:41 PM, Spies, Will <Will_Spies@comcast.com<mailto:Will_Spies@comcast.com>> wrote: Thanks for the quick response. The client is an Echo Show device and there is no log. It is an RTSP connection and my backend (behind Stunnel) is Live555ProxyServer. I read somewhere there is some bug related to MSIE that closed the connection like this and the fix is to use TIMEOUTclose=0 which I did but this did not help. This is the earlier (startup) portion of my log: 2018.07.05 05:30:45 LOG7[ui]: Clients allowed=500 2018.07.05 05:30:45 LOG5[ui]: stunnel 5.48 on x86_64-pc-linux-gnu platform 2018.07.05 05:30:45 LOG5[ui]: Compiled/running with OpenSSL 1.1.0g 2 Nov 2017 2018.07.05 05:30:45 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI 2018.07.05 05:30:45 LOG7[ui]: errno: (*__errno_location ()) 2018.07.05 05:30:45 LOG5[ui]: Reading configuration from file /etc/stunnel/stunnel.conf 2018.07.05 05:30:45 LOG5[ui]: UTF-8 byte order mark not detected 2018.07.05 05:30:45 LOG5[ui]: FIPS mode disabled 2018.07.05 05:30:45 LOG7[ui]: Compression disabled 2018.07.05 05:30:45 LOG7[ui]: No PRNG seeding was required 2018.07.05 05:30:45 LOG6[ui]: Initializing service [rtsp] 2018.07.05 05:30:45 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2018.07.05 05:30:45 LOG7[ui]: TLS options: 0x02004004 (+0x00004000, -0x00000000) 2018.07.05 05:30:45 LOG6[ui]: Loading certificate from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Certificate loaded from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Loading private key from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG4[ui]: Insecure file permissions on /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG6[ui]: Private key loaded from file: /etc/stunnel/stunnel.pem 2018.07.05 05:30:45 LOG7[ui]: Private key check succeeded 2018.07.05 05:30:45 LOG7[ui]: ECDH initialization 2018.07.05 05:30:45 LOG7[ui]: ECDH initialized with curve prime256v1 2018.07.05 05:30:45 LOG5[ui]: Configuration successful 2018.07.05 05:30:45 LOG7[ui]: Binding service [rtsp] 2018.07.05 05:30:45 LOG7[ui]: Listening file descriptor created (FD=7) 2018.07.05 05:30:45 LOG7[ui]: Setting accept socket options (FD=7) 2018.07.05 05:30:45 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2018.07.05 05:30:45 LOG6[ui]: Service [rtsp] (FD=7) bound to 192.168.112.16:443<http://192.168.112.16:443> 2018.07.05 05:30:45 LOG7[main]: No pid file being created 2018.07.05 05:30:45 LOG7[cron]: Cron thread initialized 2018.07.05 05:31:00 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:00 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:00 LOG7[main]: FD=7 events=0x2001 revents=0x1 2018.07.05 05:31:00 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.194:51692<http://192.168.112.194:51692> 2018.07.05 05:31:00 LOG7[0]: Service [rtsp] started 2018.07.05 05:31:00 LOG7[0]: Setting local socket options (FD=3) 2018.07.05 05:31:00 LOG7[0]: Option TCP_NODELAY set on local socket 2018.07.05 05:31:00 LOG5[0]: Service [rtsp] accepted connection from 192.168.112.194:51692<http://192.168.112.194:51692> 2018.07.05 05:31:00 LOG6[0]: Peer certificate not required 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): before SSL initialization 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): before SSL initialization 2018.07.05 05:31:00 LOG7[0]: SNI: no virtual services defined 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS read client hello 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write server hello 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write certificate 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write key exchange 2018.07.05 05:31:00 LOG7[0]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:00 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:00 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:00 LOG7[main]: FD=7 events=0x2001 revents=0x1 2018.07.05 05:31:00 LOG7[main]: Service [rtsp] accepted (FD=9) from 192.168.112.197:43868<http://192.168.112.197:43868> (bottom part in my original email) -----Original Message----- From: Peter Pentchev [mailto:roam@ringlet.net<mailto:roam@ringlet.net>] Sent: Thursday, July 05, 2018 7:18 AM To: Spies, Will <Will_Spies@cable.comcast.com<mailto:Will_Spies@cable.comcast.com>> Cc: stunnel-users@stunnel.org<mailto:stunnel-users@stunnel.org> Subject: [EXTERNAL] Re: [stunnel-users] Stunnel connection issue? On Thu, Jul 05, 2018 at 09:58:33AM +0000, Spies, Will wrote:
I've been trying to get Stunnel to work for some time now. I have avoided using the mail list - but I see no recourse now. I think I've tried just about every setting I could find. I appear to be getting a connection issue - but as you will see the log just doesn't indicate clearly what is going on. The behavior is my client is failing to get a connection through Stunnel to my backend. The log appears to be closing a socket (but can't tell which one frontend or backend).
Actually the log says "TLS socket closed (SSL_read)", which means that the "read some bytes from the secure socket" operation said "there are no bytes to read, the other side closed the connection", meaning your client, the one that negotiates the TLS connection with stunnel, has closed the connection immediately after stunnel considered it negotiated. The next line in the log, "0 byte(s) sent to TLS, 0 byte(s) sent to socket", says that the client did indeed not even try to send any data over the established secure connection or receive any data from it, it just closed the connection immediately after stunnel thought they had formed a chummy relationship. Is there any way you could get your client program to log verbosely what it is trying to do over the secure connection? Are there any messages on that side? G'luck, Peter -- Peter Pentchev roam@{ringlet.net<http://ringlet.net>,debian.org<http://debian.org>,FreeBSD.org} pp@storpool.com<mailto:pp@storpool.com> PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org<mailto:stunnel-users@stunnel.org> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
participants (6)
-
Daniel Trickett -
Flo Rance -
Javier -
Liz Turi -
Peter Pentchev -
Spies, Will