From patchwork Sun Nov 8 15:15:17 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gert Doering X-Patchwork-Id: 5611 Return-Path: Delivered-To: patchwork@openvpn.net Received: by 2002:a05:6022:b318:b0:119:e1c9:93e6 with SMTP id dr24csp1741580lab; Sun, 8 Nov 2026 07:15:52 -0800 (PST) X-Forwarded-Encrypted: i=2; AL+hErGo2e9S9GKsa5sJww/8qFvadkCbFEcjaJr8ea26qLtfVSMHz42/auK+i9N2b/obJUig43zw/GstKHM=@openvpn.net X-Received: by 2002:a05:693c:87dc:10b0:36a:15cb:30bf with SMTP id 5a478bee46e88-3725d1a5eabmr3643005eec.13.1794150951563; Sun, 08 Nov 2026 07:15:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1794150951; cv=none; d=google.com; s=arc-20260327; b=LkTAIhm8kypRLg/cdrenp8IG33Q4GXM2qStF+nrYcD5l1Z02zj/iPqRFhKp8MzqYYW JjNCHZzqRimZD4QLKE0YNTRQFh+/eV9f7YCuMp2gqwfsDnUXklXkfogqBn05dJ4Jx83+ fkGR6dUtDWFkwiJK0EjTFckqqCgkLIf4ZAN8tUM8sRrkf372b/OtuBYqVIAE5ZqGri5l gfAzVhHrUO6UOa5HNQEkB4KUWbFQxT8KyMKieFv1BUlVmh8wCbjgwUdc6tqPNRVg2gny ++HROGXLd+6uO81BDvSFtrSGmf5dVjBKtYDILD0hZYQE7XyudRCUf2QsW3uUN3frWvUf eODg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=errors-to:content-transfer-encoding:list-subscribe:list-help :list-post:list-archive:list-unsubscribe:list-id:precedence:subject :mime-version:references:in-reply-to:message-id:date:to:from :dkim-signature:dkim-signature:dkim-signature; bh=UlfGb+g6ti/YP8MXYG4xN/eNh3nqE/hP2YxbQUIIZAo=; fh=4NbAC/LsuMLI0S0hprUlLSLCiHwg6SCAifhH718Jh0Q=; b=qT8eEMtZXBuna6SYB8c4zX66a7LXBWWPdURwnH7dqbaF+c/x7bXUfURpZD4Xh/K5Fo YwAoe3YxlgGqTzdRg76BmUxGXymyvnSFAi2ToytiTQAYMZSqd7+EE4fMJUTtgVklQPca hlQS/TsDz/jRGUOatmGnnV2dOCBqkcQntfELo1IjlhY0Re8T3BDpaja3GgyOMexIGLF5 JzzBAekqHNiWy0mhWHvOBYgIAb4cRXNkutlmOUGwbPoXV6am7fZSTV2x6vkYw7drJhjZ ZyzGGDTKLB58GEBXcYpxhIX2eo7BDNigloyAN1X07lSicbdEvI9AkW5xtQ9E/IC+058j 76Kg==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lists.sourceforge.net header.s=beta header.b=RWPTnSrs; dkim=neutral (body hash did not verify) header.i=@sourceforge.net header.s=x header.b=DnI2RJWs; dkim=neutral (body hash did not verify) header.i=@sf.net header.s=x header.b=f17xZrwW; spf=pass (google.com: domain of openvpn-devel-bounces@lists.sourceforge.net designates 216.105.38.7 as permitted sender) smtp.mailfrom=openvpn-devel-bounces@lists.sourceforge.net; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=muc.de Received: from lists.sourceforge.net (lists.sourceforge.net. [216.105.38.7]) by mx.google.com with ESMTPS id 5a478bee46e88-372632dddf8si7446499eec.11.2026.11.08.07.15.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Nov 2026 07:15:51 -0800 (PST) Received-SPF: pass (google.com: domain of openvpn-devel-bounces@lists.sourceforge.net designates 216.105.38.7 as permitted sender) client-ip=216.105.38.7; Authentication-Results: mx.google.com; dkim=pass header.i=@lists.sourceforge.net header.s=beta header.b=RWPTnSrs; dkim=neutral (body hash did not verify) header.i=@sourceforge.net header.s=x header.b=DnI2RJWs; dkim=neutral (body hash did not verify) header.i=@sf.net header.s=x header.b=f17xZrwW; spf=pass (google.com: domain of openvpn-devel-bounces@lists.sourceforge.net designates 216.105.38.7 as permitted sender) smtp.mailfrom=openvpn-devel-bounces@lists.sourceforge.net; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=muc.de DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Subject:MIME-Version:References:In-Reply-To:Message-ID:Date:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Unsubscribe-Post: List-Owner; bh=UlfGb+g6ti/YP8MXYG4xN/eNh3nqE/hP2YxbQUIIZAo=; b=RWPTnSrsJBDXmC 0zZWxOMt+1AqnJhDWPOL+qFbqW/cUhndaZtBN1mWBSsxH8fULzi6At/DIbl3ZtP//OSD+aiUB8QiO 0eRBxLmWyIQqVcHIxzu063WRqLYUHRgk1zVbSa9+gPPMiK42UgZhywXdUiSNHWDrw7pr7goEr1+JB kik=; Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.100.1) (envelope-from ) id 1xQ4cU-000000002jw-3R4v; Sun, 08 Nov 2026 15:15:46 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.100.1) (envelope-from ) id 1xQ4cJ-000000002jl-0LeB for openvpn-devel@lists.sourceforge.net; Sun, 08 Nov 2026 15:15:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-ID:Date:Subject:To:From:Sender:Reply-To:Cc:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Unsubscribe-Post:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rUBPC2HwKfvNobk+8y936YTkw2DTxHqW2VQ7F4pFLTM=; b=DnI2RJWsbVuX2GjrOwM3nmFDLi Wk93kvDKy66i12ATzuhL6HiTwq/ygCWj1cu4Oe/bgfZJDdplRjkrpbkZGBmp8LejO9cENvmISyD2g 6PCXGFw0g/JQuN90TU2qzPJxQ0Iz4CGscGAzJf1UMeJxj1r4yTVXdN3+kry4qkZuwYUY=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID: Date:Subject:To:From:Sender:Reply-To:Cc:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Unsubscribe-Post: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rUBPC2HwKfvNobk+8y936YTkw2DTxHqW2VQ7F4pFLTM=; b=f17xZrwWYutFgzh4MnrMEPHijo iQ3/XgRPQ30XSIuAUvwWzTgVaUlU4+Gh6snQv0Huhwy+76fk8hu1ytWbXCe/08F+wYW/NLyCpGWRp SsEqZQZMUjfi3BMYd0jvE/NB//lNPJZbegWIuo0flIYFFr5IY2/QtUpHT1Lz9Tf+OK7g=; Received: from [193.149.48.129] (helo=blue.greenie.muc.de) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.100.1) id 1xQ4cH-000000006BS-1Kjv for openvpn-devel@lists.sourceforge.net; Sun, 08 Nov 2026 15:15:35 +0000 Received: from blue.greenie.muc.de (localhost [127.0.0.1]) by blue.greenie.muc.de (8.18.1/8.18.1) with ESMTP id 6A8FFNMY026285 for ; Sun, 8 Nov 2026 16:15:23 +0100 Received: (from gert@localhost) by blue.greenie.muc.de (8.18.2/8.18.1/Submit) id 6A8FFNZV026284 for openvpn-devel@lists.sourceforge.net; Sun, 8 Nov 2026 16:15:23 +0100 From: Gert Doering To: openvpn-devel@lists.sourceforge.net Date: Sun, 8 Nov 2026 16:15:17 +0100 Message-ID: <20261108151523.26265-1-gert@greenie.muc.de> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "sfi-spamd-2.hosts.colo.sdot.me", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: From: Arne Schwabe We do not need to limit the maximum ACC message length to just 1280. Also improve the comments and documentation to be clearer. Fix that the management notification about negotiated protocol is not sent when in p2p mode (or if a server has push-peer-info in its configuration) Content analysis details: (1.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS X-Headers-End: 1xQ4cH-000000006BS-1Kjv Subject: [Openvpn-devel] [PATCH v6] Adjust ACC_MAX_MSG_LEN, fix ACC in p2p mode and improve documentation 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 X-getmail-retrieved-from-mailbox: Inbox X-GMAIL-THRID: 1881303628270514132 X-GMAIL-MSGID: 1881303628270514132 From: Arne Schwabe We do not need to limit the maximum ACC message length to just 1280. Also improve the comments and documentation to be clearer. Fix that the management notification about negotiated protocol is not sent when in p2p mode (or if a server has push-peer-info in its configuration) Change-Id: I3a268fc602e916bf54853c950761977cf3d7f835 Signed-off-by: Arne Schwabe Acked-by: Razvan Cojocaru Gerrit URL: https://gerrit.openvpn.net/c/openvpn/+/2130 --- This change was reviewed on Gerrit and approved by at least one developer. I request to merge it to master. Gerrit URL: https://gerrit.openvpn.net/c/openvpn/+/2130 This mail reflects revision 6 of this Change. Acked-by according to Gerrit (reflected above): Razvan Cojocaru diff --git a/doc/management-notes.txt b/doc/management-notes.txt index 6c798c0..a98b45f 100644 --- a/doc/management-notes.txt +++ b/doc/management-notes.txt @@ -1398,11 +1398,17 @@ next message should be concatenated to this message to form a complete message. - Note that the OpenVPN implementation operates here with the robustness - principle ("be conservative in what you send, be liberal in what you - accept" - RFC 793 and others) and allows receiving messages longer than - maximum allowed message length. Implementations should be prepared to - handle messages that are longer than the maximum allowed message length. + Note that fragment is basically a flag for allowing peers communicating + over ACC to indicate if multiple ACC messages should be considered to + be a single message. If the ACC protocol is a stream based protocol + then all messages can be sent without fragment flag. + + Note that the OpenVPN implementation allows receiving messages longer than + announced maximum allowed message length. Implementations must be prepared + to handle messages that are longer than the maximum allowed message length. + Overlong messages are considered invalid and indicate that the peer is + misbehaving. Disconnecting/dropping the peer is considered a valid + response to such messages. OpenVPN does not verify that the message is valid base64. A peer that sends invalid base64 payload will be passed to the management interface. diff --git a/src/openvpn/acc.c b/src/openvpn/acc.c index 455f56d..e9656a6 100644 --- a/src/openvpn/acc.c +++ b/src/openvpn/acc.c @@ -190,10 +190,10 @@ } /* We do not check the length here. We make no promises to support - * anything larger than our announced message length but according to - * the robustness principle - * ("be conservative in what you send, be liberal in what you accept" - RFC 793 and others) - * we accept also longer messages */ + * anything larger than our announced message length but we accept also + * longer messages if they manage to get through all the other layers + * that restrict the message size like TLS_CHANNEL_BUF_SIZE. + */ int payload_len; const char *payload_len_str = buf_extract_field(&buf, ',', &gc); @@ -426,8 +426,20 @@ multi->acc_negotiated_protocols = string_alloc(buf_str(&common_protocols), NULL); multi->acc_max_message_length = max_acc_len; - setenv_str(session->opt->es, "acc_protocols", multi->acc_negotiated_protocols); - setenv_int(session->opt->es, "acc_message_len", multi->acc_max_message_length); + /* The normal case is that this is a server where we notify the client + * capabilities via environment variables */ + if (multi->opt.mode == MODE_SERVER) + { + setenv_str(session->opt->es, "acc_protocols", multi->acc_negotiated_protocols); + setenv_int(session->opt->es, "acc_message_len", multi->acc_max_message_length); + } + else + { + /* We can also end up here in p2p or if the server has --push-peer-info + * We do not set variables in that case to keep behavior consistent with + * the other paths on the client that also do not set variables */ + notify_client_acc_protocols(multi); + } gc_free(&gc); } diff --git a/src/openvpn/acc.h b/src/openvpn/acc.h index 9c99b11..d640898 100644 --- a/src/openvpn/acc.h +++ b/src/openvpn/acc.h @@ -29,7 +29,9 @@ #include "openvpn.h" #define ACC_MIN_MSG_LEN 64 -#define ACC_MAX_MSG_LEN 1280 +/* This is a conservative limit. The theoretical maximum + * is much closer to the TLS_CHANNEL_BUF_SIZE */ +#define ACC_MAX_MSG_LEN (TLS_CHANNEL_BUF_SIZE - 128) /** * This method parses an app custom control message and delivers it to the diff --git a/tests/unit_tests/openvpn/test_acc.c b/tests/unit_tests/openvpn/test_acc.c index 9364d12..bc103b4 100644 --- a/tests/unit_tests/openvpn/test_acc.c +++ b/tests/unit_tests/openvpn/test_acc.c @@ -181,7 +181,11 @@ int max_len = 0; const char *protocols = parse_acc_parameters(info_acc_msg, " ", &max_len, true, &gc); assert_string_equal(protocols, "flower:happy"); - assert_int_equal(max_len, 1280); + + /* Check that the ACC_MAX_MSG_LEN is 1920 to ensure that the tests get + * adjusted if it changes */ + assert_int_equal(ACC_MAX_MSG_LEN, 1920); + assert_int_equal(max_len, ACC_MAX_MSG_LEN); /* a client does not accept a length longer than it supports */ protocols = parse_acc_parameters(info_acc_msg, " ", &max_len, false, &gc); @@ -247,14 +251,15 @@ multi->opt.acc_protocols = c->options.acc_protocols; multi->session[TM_ACTIVE].opt = &multi->opt; multi->opt.es = env_set_create(&c->options.gc); + multi->opt.mode = MODE_SERVER; determine_common_acc_protocols(multi, &c->c2.tls_multi->session[TM_ACTIVE]); - assert_int_equal(multi->acc_max_message_length, ACC_MAX_MSG_LEN); + assert_int_equal(multi->acc_max_message_length, 1400); assert_string_equal(multi->acc_negotiated_protocols, "power:flower"); assert_string_equal(env_set_get(multi->opt.es, "acc_protocols"), "acc_protocols=power:flower"); - assert_string_equal(env_set_get(multi->opt.es, "acc_message_len"), "acc_message_len=1280"); + assert_string_equal(env_set_get(multi->opt.es, "acc_message_len"), "acc_message_len=1400"); free(multi->acc_negotiated_protocols); gc_free(&c->options.gc);