[stunnel-users] Stunnel-5.55 client close TLS socket before it could read more bytes

[Ming Lu （陆明）]

?Just an update on this issue.

My colleague Ross Lagerwall found that this was caused by server side not sending ssl alert before closing ssl connection.


A further debug shows that on server side, since "TIMEOUTclose" was configured as 0, "s_poll_wait" in "transfer" function in "src/client.c" returned as timeout immediately. This made "transfer" return without sending ssl alert to client even the "shutdown_wants_write" was 1.

?

________________________________
From: Ming Lu
Sent: Friday, December 13, 2019 17:48
To: stunnel-users at stunnel.org
Cc: Ming Lu
Subject: Stunnel-5.55 client close TLS socket before it could read more bytes


Hello,


May I please have help on this issue? Thanks in advance!


I had a stunnel server and client communicating with TLSv1.2 (both of them are stunnel 5.55 and OpenSSL-1.1.1d) on CentOS 7 based Linux (kernel was updated as 4.19.0). The case is that client sends a HTTP request to server, and then server responds a payload with more than 640KB size. Normally, the server will close the connection by sending an alert firstly.


The issue is that sometimes (not 100% reproducible), stunnel client reported: "TLS socket closed (read hangup)". and then closed the TLS socket. So I could find an alert sent from client to server firstly from tcpdump. Consequently, this caused the application reported "unexpected end of input?" as there should be more data to be received.


I added a few debug logic and I indeed found that: there were occurrences that if stunnel client did not close the TLS socket, it could read more data from TLS socket in next poll loop:


--------------------

03:59:46 localhost stunnel: LOG6[0]: MingL: POLLRDHUP: 8192
03:59:46 localhost stunnel: LOG6[0]: MingL: ioctlsocket: 0
03:59:46 localhost stunnel: LOG6[0]: MingL: bytes: 0    <== client didn't close the sock in my debug version.
03:59:46 localhost stunnel: LOG6[0]: MingL: after checking
03:59:46 localhost stunnel: LOG6[0]: MingL: s_poll_wait: return 1
03:59:46 localhost stunnel: LOG6[0]: MingL: sock_can_rd: n
03:59:46 localhost stunnel: LOG6[0]: MingL: sock_can_wr: Y
03:59:46 localhost stunnel: LOG6[0]: MingL: ssl_can_rd: n
03:59:46 localhost stunnel: LOG6[0]: MingL: ssl_can_wr: n
03:59:46 localhost stunnel: LOG6[0]: MingL: pending: 1
03:59:46 localhost stunnel: LOG6[0]: MingL: write to sock 18432
03:59:46 localhost stunnel: LOG6[0]: MingL: read_wants_read Y
03:59:46 localhost stunnel: LOG6[0]: MingL: write_wants_writen
03:59:46 localhost stunnel: LOG6[0]: MingL: read from TLS 10168  <== then I observed the further read from TLS.
--------------------


Any help will be appreciated!

Ming

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20200114/28e732c0/attachment.htm>