From patchwork Fri Apr 22 03:40:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arne Schwabe X-Patchwork-Id: 2400 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director7.mail.ord1d.rsapps.net ([172.30.191.6]) by backend41.mail.ord1d.rsapps.net with LMTP id QPruMHi+YmKOVAAAqwncew (envelope-from ) for ; Fri, 22 Apr 2022 10:40:56 -0400 Received: from proxy10.mail.ord1d.rsapps.net ([172.30.191.6]) by director7.mail.ord1d.rsapps.net with LMTP id OLH9Dnm+YmIHcwAAovjBpQ (envelope-from ) for ; Fri, 22 Apr 2022 10:40:57 -0400 Received: from smtp9.gate.ord1d ([172.30.191.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy10.mail.ord1d.rsapps.net with LMTPS id SKpeDnm+YmInEgAAfSg8FQ (envelope-from ) for ; Fri, 22 Apr 2022 10:40:57 -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: smtp9.gate.ord1d.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: 37bfa824-c24a-11ec-b28e-525400bd3b1f-1-1 Received: from [216.105.38.7] ([216.105.38.7:40022] helo=lists.sourceforge.net) by smtp9.gate.ord1d.rsapps.net (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id AF/E6-02354-87EB2626; Fri, 22 Apr 2022 10:40:56 -0400 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.94.2) (envelope-from ) id 1nhuRv-0001Ha-86; Fri, 22 Apr 2022 14:39:53 +0000 Received: from [172.30.20.202] (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.94.2) (envelope-from ) id 1nhuRt-0001HR-Uy for openvpn-devel@lists.sourceforge.net; Fri, 22 Apr 2022 14:39:52 +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: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:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1zGa4uMBtNloc/tnuhQJaWXMhNSzM8KcWxR6hquQ5mQ=; b=kPnrkyqbBcVixfiKXSTfaoJewQ +Gdn1QMZXf8oI7ZHyhkc/6SgOSdNjPLMX/i5ahs+P2RiKpQnjOpJNkv99wOSPC9H8ehcFtIJ7qjq/ xNTrJwdt4N4ZpKIKqREOhnJLA9EzzpbNYNJQnW3tYQx5CNNCc7B5101wIUxgUuIKc/v8=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:MIME-Version: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:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=1zGa4uMBtNloc/tnuhQJaWXMhNSzM8KcWxR6hquQ5mQ=; b=K MPYHA8ZnSApw6Mo7vIshR83iKOO4+6NHLVwif/lL7s0I2OjNEMS4+YP+JOed65sQE6SXSpB1FcI0b t14pZbp1dC34eTneChsdLucdukpr305NlCSpoYYXEkHxEuBrwPIQPYnaDAUcDP2Z0xkkvROpKQjqg WypINaQmpTZawacs=; Received: from mail.blinkt.de ([192.26.174.232]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.94.2) id 1nhuRr-00067t-Hf for openvpn-devel@lists.sourceforge.net; Fri, 22 Apr 2022 14:39:52 +0000 Received: from kamera.blinkt.de ([2001:638:502:390:20c:29ff:fec8:535c]) by mail.blinkt.de with smtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nhtWY-0008sC-DZ for openvpn-devel@lists.sourceforge.net; Fri, 22 Apr 2022 15:40:38 +0200 Received: (nullmailer pid 3801285 invoked by uid 10006); Fri, 22 Apr 2022 13:40:38 -0000 From: Arne Schwabe To: openvpn-devel@lists.sourceforge.net Date: Fri, 22 Apr 2022 15:40:29 +0200 Message-Id: <20220422134038.3801239-1-arne@rfc2549.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Spam-Report: Spam detection software, running on the system "util-spamd-1.v13.lw.sourceforge.com", 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: OpenVPN currently has a bit of a weakness in its early three way handshake A single client reset packet (first packet of the handshake) will - trigger creating session on the server side leading to poential ressource exhaustian - make the server respond with 3 answers trying [...] Content analysis details: (0.3 points, 6.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 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 X-Headers-End: 1nhuRr-00067t-Hf Subject: [Openvpn-devel] [PATCH 00/28] Stateless three-way handshake and control channel improvements 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 OpenVPN currently has a bit of a weakness in its early three way handshake A single client reset packet (first packet of the handshake) will - trigger creating session on the server side leading to poential ressource exhaustian - make the server respond with 3 answers trying to get an ACK for its answer making it a amplification This patch series intends to solve this problem and since the patches revolve a lot around control channel behaviour, I discovered and fixed a number of other weaknesses in the control channel implementation: - Implementing an HMAC based scheme to offer a stateless three way handshake for the server that avoids the previous mentioned problems. - Restricting control channel packet size is now possible without breaking the protocol (--tls-mtu) - Server and client will now always repeat previous ACKs to avoid the peer resending a packet if an ACK is gone missing. (Similar to what cumulative ACKs in other protocols achieve). Arne Schwabe (28): Remove tls_init_control_channel_frame_parameters wrapper function Remove dead PID_TEST code Move pre decrypt lite check to its own function Add documentation for swap_hmac function Extend tls_pre_decrypt_lite to return type of packet and keep state Move ssl function related to control channel wrap/unwrap to ssl_pkt.c/h Add unit tests for test_tls_decrypt_lite Split out reliable_ack_parse from reliable_ack_read Remove inc_pid argument from reliable_mark_deleted that is always true Remove EXPONENTIAL_BACKOFF define Refactor tls-auth/tls-crypt wrapping into into own function Extract session_move_pre_start as own function, use local buffer variable Change FULL_SYNC macro to no_pending_reliable_packets function Move tls_process_state into its own function Remove pointless indentation from tls_process. Move CRL reload to key_state_init from S_START transition Implement constructing a control channel reset client as standalone fucntion Implement stateless, HMAC basedsesssion id three way handshake Make buf_write_u8/16/32 take the type they pretend to take Change reliable_get_buf_sequenced to reliable_get_entry_sequenced Extract read_incoming_tls_ciphertext into function Implement HMAC based session id for tls-crypt v2 Optimise three-way handshake condition for S_PRE_START to S_START Extract read_incoming_tls_plaintext into its own function Ensure that control channel packet are respecting tls-mtu Allow setting control channel packet size with tls-mtu Add unit test for reliable_get_num_output_sequenced_available Always include ACKs for the last seen control packets Changes.rst | 16 + doc/doxygen/doc_protocol_overview.h | 2 + doc/man-sections/link-options.rst | 7 + doc/man-sections/tls-options.rst | 14 + doc/tls-crypt-v2.txt | 41 + src/openvpn/Makefile.am | 1 + src/openvpn/buffer.h | 13 +- src/openvpn/crypto.h | 8 + src/openvpn/init.c | 28 +- src/openvpn/mtu.h | 5 + src/openvpn/mudp.c | 164 ++- src/openvpn/multi.h | 3 + src/openvpn/openvpn.h | 6 + src/openvpn/openvpn.vcxproj | 2 + src/openvpn/openvpn.vcxproj.filters | 3 + src/openvpn/options.c | 27 + src/openvpn/options.h | 4 + src/openvpn/packet_id.c | 56 - src/openvpn/packet_id.h | 25 +- src/openvpn/reliable.c | 209 +++- src/openvpn/reliable.h | 84 +- src/openvpn/ssl.c | 1312 ++++++++++---------- src/openvpn/ssl.h | 97 +- src/openvpn/ssl_backend.h | 8 +- src/openvpn/ssl_common.h | 1 + src/openvpn/ssl_mbedtls.c | 19 +- src/openvpn/ssl_mbedtls.h | 4 + src/openvpn/ssl_openssl.c | 22 +- src/openvpn/ssl_openssl.h | 7 + src/openvpn/ssl_pkt.c | 549 ++++++++ src/openvpn/ssl_pkt.h | 295 +++++ tests/unit_tests/openvpn/Makefile.am | 29 +- tests/unit_tests/openvpn/mock_get_random.c | 10 + tests/unit_tests/openvpn/test_packet_id.c | 90 ++ tests/unit_tests/openvpn/test_pkt.c | 620 +++++++++ 35 files changed, 2825 insertions(+), 956 deletions(-) create mode 100644 src/openvpn/ssl_pkt.c create mode 100644 src/openvpn/ssl_pkt.h create mode 100644 tests/unit_tests/openvpn/test_pkt.c