[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1041555: marked as done (bookworm-pu: package stunnel4/3:5.68-2+deb12u1)

Your message dated Sat, 07 Oct 2023 09:59:38 +0000
with message-id <E1qp45y-00A4B0-U4@coccia.debian.org>
and subject line Released with 12.2
has caused the Debian Bug report #1041555,
regarding bookworm-pu: package stunnel4/3:5.68-2+deb12u1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1041555: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041555
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian.org@packages.debian.org
Usertags: pu
X-Debbugs-Cc: stunnel4@packages.debian.org, roam@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.000000000 +0200
+++ stunnel4-5.68/debian/changelog	2023-07-20 22:01:31.000000000 +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 <roam@debian.org>  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.000000000 +0200
+++ stunnel4-5.68/debian/patches/08-tls-eof.patch	2023-07-20 22:00:46.000000000 +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
+Origin: upstream
+Author: Michal Trojnara <Michal.Trojnara@stunnel.org>
+Last-Update: 2023-07-20
+
+--- a/src/client.c
++++ b/src/client.c
+@@ -1118,6 +1118,24 @@
+                     "SSL_read returned WANT_X509_LOOKUP: retrying");
+                 break;
+             case SSL_ERROR_SSL:
++#ifdef SSL_R_UNEXPECTED_EOF_WHILE_READING
++                /* OpenSSL 3.0 changed the method of reporting socket EOF */
++                if(ERR_GET_REASON(ERR_peek_error())==
++                        SSL_R_UNEXPECTED_EOF_WHILE_READING) {
++                    /* EOF -> buggy (e.g. Microsoft) peer:
++                    * TLS socket closed without close_notify alert */
++                    if(c->sock_ptr || write_wants_write) {
++                        s_log(LOG_ERR,
++                            "TLS socket closed (SSL_read) with %ld unsent byte(s)",
++                            (long)c->sock_ptr);
++                        throw_exception(c, 1); /* reset the sockets */
++                    }
++                    s_log(LOG_INFO, "TLS socket closed (SSL_read)");
++                    SSL_set_shutdown(c->ssl,
++                        SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN);
++                    break;
++                }
++#endif /* SSL_R_UNEXPECTED_EOF_WHILE_READING */
+                 sslerror("SSL_read");
+                 throw_exception(c, 1);
+             case SSL_ERROR_ZERO_RETURN: /* received a close_notify alert */
diff -Nru stunnel4-5.68/debian/patches/series stunnel4-5.68/debian/patches/series
--- stunnel4-5.68/debian/patches/series	2023-02-12 13:40:09.000000000 +0200
+++ stunnel4-5.68/debian/patches/series	2023-07-20 21:57:26.000000000 +0300
@@ -4,3 +4,4 @@
 05-sample-sysconfdir.patch
 06-no-openssl-version-check-autopkgtest.patch
 07-tests-errmsg.patch
+08-tls-eof.patch

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
Version: 12.2

The upload requested in this bug has been released as part of 12.2.

--- End Message ---
Reply to: