Date: Thu, 23 Dec 2021 23:06:59 +0500 From: "Alexander E. Patrakov" <patrakov@...il.com> To: oss-security@...ts.openwall.com Subject: CVE-2021-44273: e2guardian did not validate TLS hostnames Hello! Some time ago I was trying to make a certain Arch Linux system compliant with CyberEssentials security requirements from the UK , and this includes the requirement for anti-virus scanning of all web browser traffic. I interpreted this literally: break TLS using MITM on the (transparent) proxy, scan everything with ClamAV. Note: I may be mis-interpreting and over-complying, there is an unverified opinion that anti-malware browser extensions are enough and that it is not needed to break TLS. I don't know. Anyway, I have decided to try e2guardian 5.4.3r and later a 5.5 git snapshot, in the standalone mode (where it functions as a transparent proxy, as opposed to an ICAP server), because of the apparent simplicity of its setup. While testing it, I found that it significantly lowered the security of the system it purported to protect: I was able to access, through this transparent proxy, a significant amount of badssl.com subdomains that should not be accessible. In particular, I was able to access wrong.host.badssl.com, which meant that SSL certificate hostname validation was not working, and an attacker could trivially MITM the connection from the origin server to e2guardian. I have reported this , and it is now fixed in the v5.4 branch . There is still no formal release with the fix. I do not see anything relevant on the v5.5dev branch, though, and I have not tested any other branches. The issue exists only if e2guardian is compiled against OpenSSL 1.1.x, and is operating in the standalone mode. Builds using OpenSSL 1.0.2 or operating as ICAP servers (as opposed to standalone transparent proxies) are not affected. This issue with missing TLS hostname validation is now known as CVE-2021-44273. Distribution package maintainers, please see if your e2guardian package is vulnerable. I have also reported  another issue, that certain badssl.com subdomains that implement bad crypto (dh2048, dh-small-subgroup, dh-composite, tls-v1-0, tls-v1-1), normally rejected by browsers, are still accessible through the e2guardian transparent proxy. However, we have agreed that it is not a bug in e2guardian, but just insecure OpenSSL defaults (and no user-oriented documentation how to change them via openssl.cnf), because the same subdomains can be accessed via curl. Interestingly, Squid (with ssl-bump enabled) does disallow such bad crypto. In my personal opinion (which may be different from the official opinion of any company that I work or worked for), the incident described above, plus a similar recent incident with Squid (CVE-2021-41611), should be treated as an evidence that such "please MITM all SSL traffic" requirements actually lower the security and should be abandoned, merely because browsers de-facto have the best available quality of TLS implementations.  https://www.ncsc.gov.uk/files/Cyber-Essentials-Requirements-for-IT-infrastructure-2-2.pdf  https://github.com/e2guardian/e2guardian/issues/707  https://github.com/e2guardian/e2guardian/commit/eae46a7e2a57103aadca903c4a24cca94dc502a2  https://github.com/e2guardian/e2guardian/issues/708 -- Alexander E. Patrakov
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.