Bug#966395: Please support SSL bumping with '--with-openssl' configure option
On Wed, Jul 29, 2020 at 10:09:45AM +1200, Amos Jeffries wrote: > On Mon, 27 Jul 2020 17:54:01 -0400 Simon Deziel wrote: > > > > Now that OpenSSL is available under the Apache License v. 2.0, there > > should no longer be any incompatibility with Debian. > > > Apache is not yet available with the new License and will likely not be > until the next Debian major release after it becomes available. You don't need to wait for OpenSSL 3; FTP masters have decided to treat OpenSSL as a system library like glibc, which makes it compatible, see http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-03-13-20.02.html Cheers, Moritz
Bug#966395: Please support SSL bumping with '--with-openssl' configure option
Package: squid Version: 4.6-1+deb10u3 Followup-For: Bug #966395 Dear Maintainer, I have attempted to use the squid package using plain-text input to the proxy, but a https URL, which exercises some of the same code paths as SSL bumping configurations, and have investigated further why this doesn't work with gnutls. It seems that the key log line (visible with debugging verbosity of 8) is 2020/08/15 12:14:50.252 kid1| 5,3| Read.cc(92) ReadNow: local=192.168.0.4:51944 remote=142.250.67.14:443 FD 15 flags=1, size 65536, retval -28, errno 0 It turns out that -28 means GNUTLS_E_AGAIN. This should be a non-fatal error, but squid looks in errno to decide if an error is fatal, not in the return value. But gnutls just returns the value, it doesn't set the errno: https://gitlab.com/gnutls/gnutls/-/blob/master/lib/buffers.c#L617 So this seems like a squid upstream bug with how it integrates with gnutls. I haven't had any success signing up for upstream's Bugzilla, so haven't been able to report this to upstream yet. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages squid depends on: ii adduser 3.118 ii libc62.28-10 ii libcap2 1:2.25-2 ii libcom-err2 1.44.5-1+deb10u3 ii libdb5.3 5.3.28+dfsg1-0.5 ii libdbi-perl 1.642-1+b1 ii libecap3 1.0.1-3.2 ii libexpat12.2.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4+deb10u5 ii libgssapi-krb5-2 1.17-3 ii libkrb5-31.17-3 ii libldap-2.4-22.4.47+dfsg-3+deb10u2 ii libltdl7 2.4.6-9 ii libnetfilter-conntrack3 1.0.7-1 ii libnettle6 3.4.1-1 ii libpam0g 1.3.1-5 ii libsasl2-2 2.1.27+dfsg-1+deb10u1 ii libstdc++6 8.3.0-6 ii libxml2 2.9.4+dfsg1-7+b3 ii logrotate3.14.0-4 ii lsb-base 10.2019051400 ii netbase 5.6 ii squid-common 4.6-1+deb10u3 Versions of packages squid recommends: ii ca-certificates 20190110 ii libcap2-bin 1:2.25-2 Versions of packages squid suggests: ii resolvconf 1.79 ii smbclient2:4.9.5+dfsg-5+deb10u1 pn squid-cgi pn squid-purge ii squidclient 4.6-1+deb10u3 ii ufw 0.36-1 ii winbind 2:4.9.5+dfsg-5+deb10u1 -- no debconf information
Bug#966395: Please support SSL bumping with '--with-openssl' configure option
On Mon, 27 Jul 2020 17:54:01 -0400 Simon Deziel wrote: > > Now that OpenSSL is available under the Apache License v. 2.0, there > should no longer be any incompatibility with Debian. Apache is not yet available with the new License and will likely not be until the next Debian major release after it becomes available. FWIW; Upstream is working on a few updates necessary for Squid to build with libssl3 so this should happen normally when all the supporting versions are available to install. Amos
Bug#966395: Please support SSL bumping with '--with-openssl' configure option
Package: squid Version: 4.12-1 In order to do SSL bumping [1], it seems that squid needs to be configured '--with-openssl'. I believe that Debian chose to use GnuTLS due to license incompatibility with OpenSSL. OpenSSL went through the process of re-licensing and were able to do so in 2017 according to: https://www.openssl.org/blog/blog/2017/03/22/license/ Now that OpenSSL is available under the Apache License v. 2.0, there should no longer be any incompatibility with Debian. As such, it would be great to benefit from the more features oferred by builds using --with-openssl. Justification/use cases: Nowadays, HTTPS represents the majority of the traffic and it cannot be observed as easily as HTTP. With SSL bumping, squid can use the SNI header that is (still) in the cleartext portion of the SSL/TLS connection and use that to allow/deny forwarding the connection. That is the 'peek-n-splice' mode in upstream docs [2]. This mode doesn't compromise the security/privacy of the intercepted traffic as SSL/TLS is not terminated. The SNI inspection may be considered a privacy concern by some. One can also do fancier things like implementing a corporate MITM that generates certs on the fly signed by locally trusted CA [3]. This terminates the SSL/TLS connection in order to inspect the inner communication. This "intrusion" is sometimes required by organization policies. I can only speak for my organization but we ran into multiple situations where the peek-n-splice capability would have been handy. In other scenarios, we would have appreciated the MITM version too, so I think there is demand for such feature. Regards, Simon 1: https://wiki.squid-cache.org/Features/SslBump 2: https://wiki.squid-cache.org/Features/SslPeekAndSplice 3: https://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
