From patchwork Fri Oct 23 01:02:59 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arne Schwabe X-Patchwork-Id: 1526 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director9.mail.ord1d.rsapps.net ([172.27.255.1]) by backend41.mail.ord1d.rsapps.net with LMTP id YFfMK8LGkl+iCwAAqwncew (envelope-from ) for ; Fri, 23 Oct 2020 08:04:18 -0400 Received: from proxy4.mail.iad3a.rsapps.net ([172.27.255.1]) by director9.mail.ord1d.rsapps.net with LMTP id KIyiK8LGkl9GFgAAalYnBA (envelope-from ) for ; Fri, 23 Oct 2020 08:04:18 -0400 Received: from smtp32.gate.iad3a ([172.27.255.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy4.mail.iad3a.rsapps.net with LMTPS id 8CspJMLGkl/vawAA8Zvu4w (envelope-from ) for ; Fri, 23 Oct 2020 08:04:18 -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: smtp32.gate.iad3a.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; dmarc=none (p=nil; dis=none) header.from=rfc2549.org X-Suspicious-Flag: YES X-Classification-ID: e0178572-1527-11eb-9424-5254001741cc-1-1 Received: from [216.105.38.7] ([216.105.38.7:54056] helo=lists.sourceforge.net) by smtp32.gate.iad3a.rsapps.net (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 6F/A8-31471-1C6C29F5; Fri, 23 Oct 2020 08:04:18 -0400 Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kVvmt-0005gc-2d; Fri, 23 Oct 2020 12:03:15 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kVvmr-0005gF-Dh for openvpn-devel@lists.sourceforge.net; Fri, 23 Oct 2020 12:03:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=References:In-Reply-To:Message-Id:Date:Subject:To: From:Sender:Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0zOR5d6Dgi+TSD+db+dXRMJ+JFDrZbSrAVzxtz7zAVU=; b=IU24yHYISTTXWTHBKoKW4QtrxU 3r4dWtedsNGMe5ee4V698DIt9CX+uUsEuIE+/sY2T6n9qbbUVRuiaje//1IEqUDYG9M+jRBlQBBOQ TJb1vc9O78MHHyShRrBJLq9+dIhQVOe65FOHfaOORbxhzULAFlqy/5mC8n9+9+lrw/LM=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=References:In-Reply-To:Message-Id:Date:Subject:To:From:Sender:Reply-To:Cc :MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0zOR5d6Dgi+TSD+db+dXRMJ+JFDrZbSrAVzxtz7zAVU=; b=hbzppksChIcyIMMYdidEa4oHNC Mg6QvSm8c28jUiLaQ3IIDxG7XU7ggzYJeG7yoycLuPA0q3UtwIxWWOeGCqbeYBNYJYcb/KR0ZhWgh 3+ROq4wwoAt/YBCWfSOItZYOPazN7bcdIz2xxypPhAlyf4G47HxIUCpOEle0DCRj0RUo=; Received: from mail.blinkt.de ([192.26.174.232]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1kVvml-00A3wV-1U for openvpn-devel@lists.sourceforge.net; Fri, 23 Oct 2020 12:03:13 +0000 Received: from kamera.blinkt.de ([2001:638:502:390:20c:29ff:fec8:535c]) by mail.blinkt.de with smtp (Exim 4.94 (FreeBSD)) (envelope-from ) id 1kVvme-000JG3-7l for openvpn-devel@lists.sourceforge.net; Fri, 23 Oct 2020 14:03:00 +0200 Received: (nullmailer pid 29847 invoked by uid 10006); Fri, 23 Oct 2020 12:03:00 -0000 From: Arne Schwabe To: openvpn-devel@lists.sourceforge.net Date: Fri, 23 Oct 2020 14:02:59 +0200 Message-Id: <20201023120259.29783-7-arne@rfc2549.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20201023120259.29783-1-arne@rfc2549.org> References: <20201023113244.26295-1-arne@rfc2549.org> <20201023120259.29783-1-arne@rfc2549.org> X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: rfc2549.org] 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_NONE SPF: sender does not publish an SPF Record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record X-Headers-End: 1kVvml-00A3wV-1U Subject: [Openvpn-devel] [PATCH 8/8] Make any auth failure tls_authentication_status return auth failed 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: , MIME-Version: 1.0 Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox Previously tls_authentication_status only return TLS_AUTHENTICATION_FAILED if there is no usable key at all. This behaviour allows continuing using the still valid keys (see --tran-window). However, the OpenVPN protocol lacks a way of communicating that key is not useable to client once it reached the TLS authenticated status (eg cert checks pass but connect or user-pass verify fail). To avoid these desynchronisation issues during deferred auth and renegotiation OpenVPN quietly only starts using a new key after the hand-window has passed. With this change any failure on a renogiation will lead to a deauthentication of a client. This also fixes a number of bugs that expiring auth-token and failed deferred auth is leading to key desync or unexpected continuation of the VPN session. The behaviour of deauthentication of all keys on deferred auth failure has been already been used for years if authentication is done via management interface. This commit also aligns the code paths for both. A side effect might be that we also deauth clients earlier in some other corner cases but the behaviour of continuing using an old authenticated session while we already a failed authentication for the client is most times unexpected behaviour from the user (admin). Signed-off-by: Arne Schwabe Acked-by: Gert Doering --- src/openvpn/multi.c | 12 ++---------- src/openvpn/ssl_verify.c | 25 +++++++++++++++++++++---- 2 files changed, 23 insertions(+), 14 deletions(-) diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c index 9becb2b2..401dfa8e 100644 --- a/src/openvpn/multi.c +++ b/src/openvpn/multi.c @@ -3963,17 +3963,9 @@ management_client_auth(void *arg, cc_config_owned = false; } } - else + else if (reason) { - if (reason) - { - msg(D_MULTI_LOW, "MULTI: connection rejected: %s, CLI:%s", reason, np(client_reason)); - } - if (!is_cas_pending(mi->context.c2.context_auth)) - { - send_auth_failed(&mi->context, client_reason); /* mid-session reauth failed */ - multi_schedule_context_wakeup(m, mi); - } + msg(D_MULTI_LOW, "MULTI: connection rejected: %s, CLI:%s", reason, np(client_reason)); } } } diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c index 98985c51..a4538d38 100644 --- a/src/openvpn/ssl_verify.c +++ b/src/openvpn/ssl_verify.c @@ -939,6 +939,9 @@ tls_authentication_status(struct tls_multi *multi, const int latency) /* at least one key is enabled for decryption */ int active = 0; + /* at least one key already failed authentication */ + bool failed_auth = false; + if (latency && multi->tas_last + latency >= now) { return TLS_AUTHENTICATION_UNDEFINED; @@ -951,7 +954,11 @@ tls_authentication_status(struct tls_multi *multi, const int latency) if (TLS_AUTHENTICATED(multi, ks)) { active++; - if (ks->authenticated > KS_AUTH_FALSE) + if (ks->authenticated == KS_AUTH_FALSE) + { + failed_auth = true; + } + else { unsigned int s1 = ACF_DISABLED; unsigned int s2 = ACF_DISABLED; @@ -964,6 +971,7 @@ tls_authentication_status(struct tls_multi *multi, const int latency) if (s1 == ACF_FAILED || s2 == ACF_FAILED) { ks->authenticated = KS_AUTH_FALSE; + failed_auth = true; } else if (s1 == ACF_UNDEFINED || s2 == ACF_UNDEFINED) { @@ -983,10 +991,19 @@ tls_authentication_status(struct tls_multi *multi, const int latency) } #if 0 - dmsg(D_TLS_ERRORS, "TAS: a=%d s=%d d=%d", active, success, deferred); + dmsg(D_TLS_ERRORS, "TAS: a=%d s=%d d=%d f=%d", active, success, deferred, failed_auth); #endif - - if (success) + if (failed_auth) + { + /* We have at least one session that failed authentication. There + * might be still another session with valid keys. + * Although our protocol allows keeping the VPN session alive + * with the other session (and we actually did that in earlier + * version, this behaviour is really strange from a user (admin) + * experience */ + return TLS_AUTHENTICATION_FAILED; + } + else if (success) { return TLS_AUTHENTICATION_SUCCEEDED; }