From patchwork Fri Apr 2 00:24:02 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maximilian Fillinger X-Patchwork-Id: 1700 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director14.mail.ord1d.rsapps.net ([172.30.191.6]) by backend30.mail.ord1d.rsapps.net with LMTP id 6EiSBU7/ZmA5XwAAIUCqbw (envelope-from ) for ; Fri, 02 Apr 2021 07:26:06 -0400 Received: from proxy5.mail.ord1d.rsapps.net ([172.30.191.6]) by director14.mail.ord1d.rsapps.net with LMTP id CAVXBU7/ZmCxOgAAeJ7fFg (envelope-from ) for ; Fri, 02 Apr 2021 07:26:06 -0400 Received: from smtp26.gate.ord1c ([172.30.191.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy5.mail.ord1d.rsapps.net with LMTPS id qEERBU7/ZmDYDwAA8Zzt7w (envelope-from ) for ; Fri, 02 Apr 2021 07:26:06 -0400 X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO X-Virus-Scanned: OK X-Orig-To: openvpnslackdevel@openvpn.net X-Originating-Ip: [216.105.38.7] Authentication-Results: smtp26.gate.ord1c.rsapps.net; iprev=pass policy.iprev="216.105.38.7"; spf=pass smtp.mailfrom="openvpn-devel-bounces@lists.sourceforge.net" smtp.helo="lists.sourceforge.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dkim=fail (key not found in DNS) header.d=foxcrypto.com; dmarc=fail (p=none; dis=none) header.from=foxcrypto.com X-Suspicious-Flag: YES X-Classification-ID: 36826b82-93a6-11eb-b41a-b8ca3a5bd12c-1-1 Received: from [216.105.38.7] ([216.105.38.7:59934] helo=lists.sourceforge.net) by smtp26.gate.ord1c.rsapps.net (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id DC/A5-23448-D4FF6606; Fri, 02 Apr 2021 07:26:05 -0400 Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lSHvL-0007TM-Ii; Fri, 02 Apr 2021 11:25:11 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lSHvK-0007Ss-0D for openvpn-devel@lists.sourceforge.net; Fri, 02 Apr 2021 11:25:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:MIME-Version:Date:Subject:CC:To:From: Sender:Reply-To:Message-ID:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VStdDD1A3YhbCecWS+jW/dtU3di3RFb1pQKb/HZyil8=; b=hlwtENF27vMzFSzZ3/4gh6OfoD yeCtZLD5dpqsM/EKYJf5IgiAdA0ScBDkS1GT+p23INgBhS5lq05CfMhXgmH6aTyTpVJ++zRSTudSJ VliY21kVuDEDWbwTtyAjqeMz7aWllAl4dkbFy/3RF5RoGJku2a6EDQt9HkSMnfhufhkw=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:MIME-Version:Date:Subject:CC:To:From:Sender:Reply-To: Message-ID:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VStdDD1A3YhbCecWS+jW/dtU3di3RFb1pQKb/HZyil8=; b=RkerjAcVWK9dDK0W+pX9EFznfn U35DSW2MVUoVEnUeWX0XFEQkCKIU6wuQvFVr/wcSXN8wHMkMtCg6CapCix18aNWEb2AfXG4BdaiUd Vw7sxxub8bCTCvhpQVMkpr6BHs/hLY8A9ncGpx9W3T8rIRHKl2+5ax9badUrVZ6z3RN4=; Received: from nl-dft-mx-01.fox-it.com ([178.250.144.135]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) id 1lSHuu-0001E0-0i for openvpn-devel@lists.sourceforge.net; Fri, 02 Apr 2021 11:25:09 +0000 From: Max Fillinger To: Date: Fri, 2 Apr 2021 13:24:02 +0200 X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 X-ClientProxiedBy: FOXDFT1EX01.FOX.local (10.0.0.129) To FOXDFT1EX01.FOX.local (10.0.0.129) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=foxcrypto.com; s=NL-DFT-MX-01; c=relaxed/relaxed; h=from:to:cc:subject:date:mime-version:content-type; bh=VStdDD1A3YhbCecWS+jW/dtU3di3RFb1pQKb/HZyil8=; b=xsbQ+TNYc8v9V16nxATi6H99ZadkAJWdiNwENWbCistuJdZ23UUA+44hFcaaM1Aa1hqLEzMqxke5 qEIfw6ZXaCBMGZ4cF21RFmAB0v0Hx+gNNo572LOrbbDKJmk3F1tPwzplkyr2eKtuelDrGHYAF683 Np+PIwOQIfYeV5Xl1Mq8i60/moTxXYZE9MfCLRtocPCDF7769sg9Qgo1hO4Ix1gkK3brc7HwY/CM rrq+aWIbUFLjSBlI/mFjk1cf7txinAQfJYLJOxPI5aNYudDZPL8dl4bNyWxdx+te47uU5w/bLV9L 354Jz1MvXb5RoA7OH3ySlCv+sWXbd1uiBPD1pw== X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline X-Headers-End: 1lSHuu-0001E0-0i Subject: [Openvpn-devel] [PATCH 0/1] CRL reloading issue with mbedTLS and chroot X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: openvpn-devel-bounces@lists.sourceforge.net Message-Id: X-getmail-retrieved-from-mailbox: Inbox There is an issue with the mbedTLS version of OpenVPN where a CRL file wouldn't be used when running in a chroot. This is due to a combination of two bugs found by Adam Lukosek at Compumatica. 1) With mbedTLS, if the CRL file can't be opened during initialization, OpenVPN will read the file when it becomes available later, but it will not actually use it. This situation is likely to happen when running in a chroot because... 2) When a file needs to be opened both pre- and post-chroot, OpenVPN will try to open the path outside of the chroot directory. For example, let's say we have the CRL file in "/chroot/crl.pem", and we run OpenVPN with "--chroot /chroot/" and "--crl-verify /crl.pem". During option validation, OpenVPN will check that "/chroot/crl.pem" exists. Pre-chroot, it will try to open "/crl.pem", which fails. Post-chroot, it opens the file. In my patch, I fix issue 1). I don't find it very elegant, but the only other solution I saw was to add function arguments to ssl_backend.h functions that are only relevant for mbedTLS. I'd be happy to hear other suggestions! I think that issue 2) should be addressed as well. Reloading CRLs does work with OpenSSL, but there's still a possibility that OpenVPN reads different files pre- and post-chroot. (E.g., imagine a user updates "/crl.pem" but forgets "/chroot/crl.pem".) I would like to always prefix the chroot-path when opening a file that needs to be available post-chroot during init. However, this might break some existing setups. Does that seem like a good idea to you? Finally, I noticed a behavior that seems inconsistent to me: When OpenVPN cannot parse a CRL file, it will reject all connection attempts. When it cannot stat a CRL file, it will continue without a CRL. Is there a reason why it has to work that way? I saw this behavior with both mbedTLS and OpenSSL. My patch accidentally fixed it for mbedTLS. Maximilian Fillinger (1): Let mbedtls_ssl_configs find reloaded CRLs src/openvpn/ssl.c | 11 +++++++++++ src/openvpn/ssl_mbedtls.c | 13 +++++++++++++ src/openvpn/ssl_mbedtls.h | 3 +++ 3 files changed, 27 insertions(+)