Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: stunn...@packages.debian.org, r...@debian.org
Control: affects -1 + src:stunnel4
Hi,
This is a pre-approval request before I upload an update to
the stunnel4 package targetting bookworm to fix a bug in
the handling of improperly closed TLS connections; see #1041545.
The patch was taken from stunnel4 version 5.70 that I just
uploaded to unstable.
[ Reason ]
In versions before 5.70, stunnel4 fails to recognize a new OpenSSL 3.x
error code that signals that the remote side closed the network
connection without performing a proper TLS shutdown. Instead, stunnel
treats this situation as an error.
If there was any pending data that the stunnel service had enqueued for
sending over the encrypted connection, it is discarded, so if the TLS
session is later resumed, the encrypted data stream will be corrupted.
[ Impact ]
Quoting from the changelog entry for version 5.70:
- Fixed TLS socket EOF handling with OpenSSL 3.x.
This bug caused major interoperability issues between
stunnel built with OpenSSL 3.x and Microsoft's
Schannel Security Support Provider (SSP).
The stunnel4 version in bookworm can fail to interoperate with
some TLS applications, thus rendering the package unusable for
people who want to set up such tunnels.
[ Tests ]
For the present there are no automated tests for this problem, but
it can be reproduced manually using the following procedure:
- set up a tunnel in non-client mode (stunnel4 accepts TLS connections
and forwards to a plain-text service) listening on e.g. a loopback
address and forwarding to e.g. another port on the loopback address
- start (or restart) the stunnel4 service (a systemd user service will
work just as well) so that it listens for incoming TLS connections
- start a program that listens for plain-text connections, e.g.
`nc -v -l 127.0.0.2 8086`
- use `openssl s_client -connect ...` to connect to the stunnel instance
- type a couple of words on both sides to make sure data is being
forwarded correctly
- kill the OpenSSL `s_client` process using e.g. an ABRT or FPE signal so
that it does not get a chance to perform the proper TLS shutdown
- look for an error message in the logs of the stunnel service;
the error may look like:
"LOG3[0]: SSL_read: ../ssl/record/rec_layer_s3.c:303:
error:0A000126:SSL routines::unexpected eof while reading"
The appearance of this error message means that stunnel has failed to
recognize the OpenSSL error code that signifies an unexpectedly closed
network connection, and treats it as an error instead of a closed
connection. With the attached patch, stunnel will instead report
"LOG6[1]: TLS socket closed (SSL_read)".
[ Risks ]
The code is easy to follow for people familiar with the C language;
it is a no-op if the OpenSSL version used does not support that particular
error code, and if it does, it is recognized and treated as a closed
network connection event.
In my opinion the risk is minimal, if any at all.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
A new patch is added as the debian/patches/08-tls-eof.patch file;
it adds several lines to the "handle an SSL error" case in
the src/client.c file.
diff -Nru stunnel4-5.68/debian/changelog stunnel4-5.68/debian/changelog
--- stunnel4-5.68/debian/changelog 2023-02-12 13:40:09.0 +0200
+++ stunnel4-5.68/debian/changelog 2023-07-20 22:01:31.0 +0300
@@ -1,3 +1,11 @@
+stunnel4 (3:5.68-2+deb12u1) bookworm; urgency=medium
+
+ * Add the 08-tls-eof patch to fix the handling of a peer closing
+a TLS connection without proper TLS shutdown messaging.
+Closes: #1041545
+
+ -- Peter Pentchev Thu, 20 Jul 2023 22:01:31 +0300
+
stunnel4 (3:5.68-2) unstable; urgency=medium
* Add the 07-tests-errmsg patch to fix the FTBFS on several architectures
diff -Nru stunnel4-5.68/debian/patches/08-tls-eof.patch
stunnel4-5.68/debian/patches/08-tls-eof.patch
--- stunnel4-5.68/debian/patches/08-tls-eof.patch 1970-01-01
02:00:00.0 +0200
+++ stunnel4-5.68/debian/patches/08-tls-eof.patch 2023-07-20
22:00:46.0 +0300
@@ -0,0 +1,41 @@
+Description: Fix handling of socket closed without TLS shuttdown
+ In versions before 5.70, stunnel4 fails to recognize a new OpenSSL 3.x
+ error code that signals that the remote side closed the network
+ connection without performing a proper TLS shutdown. Instead, stunnel
+ treats this situation as an error.
+ .
+ If there was any pending data that the stunnel service had enqueued for
+ sending over the encrypted connection, it is discarded, so if the TLS
+ session is later resumed, the encrypted data stream will be corrupted.
+Bug-Debian: https://bugs.debian.org/1041545
