From patchwork Wed Jun 24 08:07:40 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Sommerseth X-Patchwork-Id: 1171 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director8.mail.ord1d.rsapps.net ([172.30.191.6]) by backend30.mail.ord1d.rsapps.net with LMTP id aLoyHimX817rPAAAIUCqbw for ; Wed, 24 Jun 2020 14:10:49 -0400 Received: from proxy15.mail.ord1d.rsapps.net ([172.30.191.6]) by director8.mail.ord1d.rsapps.net with LMTP id 2M70HSmX816KOgAAfY0hYg ; Wed, 24 Jun 2020 14:10:49 -0400 Received: from smtp26.gate.ord1d ([172.30.191.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy15.mail.ord1d.rsapps.net with LMTP id ULI6HSmX815hLwAAAY1PeQ ; Wed, 24 Jun 2020 14:10:49 -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.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=fail (p=none; dis=none) header.from=openvpn.net X-Suspicious-Flag: YES X-Classification-ID: 07dc8850-b646-11ea-a3d4-525400c5b129-1-1 Received: from [216.105.38.7] ([216.105.38.7:45108] helo=lists.sourceforge.net) by smtp26.gate.ord1d.rsapps.net (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 89/07-31890-82793FE5; Wed, 24 Jun 2020 14:10:49 -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.90_1) (envelope-from ) id 1jo9qW-0001Xi-ER; Wed, 24 Jun 2020 18:10:04 +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.90_1) (envelope-from ) id 1jo9qT-0001XI-Uz for openvpn-devel@lists.sourceforge.net; Wed, 24 Jun 2020 18:10:01 +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-Subscribe:List-Post:List-Owner:List-Archive; bh=vgOuTK9w51m7jOV2jTb/t4znnQenxHg9pr1R3uAKj3A=; b=m53PMd/CrfXo9NbE/4tfv3xsbW VuUL4tu0m68+aILFI4OpvmI9Yu+fXF54STe6Phl8As3FxaEMc3uWxu2fou+/ga7MxPXBrVZnJ4u/l 4fggw/vZHE0D1hKcTbqYJjXibphJfnU2gvlLPhpcL2/sxShJH7zNmLhRtmtTTfvhbS2s=; 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-Subscribe: List-Post:List-Owner:List-Archive; bh=vgOuTK9w51m7jOV2jTb/t4znnQenxHg9pr1R3uAKj3A=; b=B7cgK9E2In3Lr/tvOQQsYkkmhn LG8jx03rjPurvPNk7O42TiIVbzSFm8VnoXkb0/XxgJSHpD/H411OY3AcZDgcimeWT6fR7/h07heQe 8z70pkKd+hW9FXQWo3qcGhx3AAMFHchPuaawAprc17So7ZUD7EKD8jFfLT5Wg/VtOKhU=; Received: from mx0.basenordic.cloud ([185.212.44.139]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1jo9qS-00EFCy-1L for openvpn-devel@lists.sourceforge.net; Wed, 24 Jun 2020 18:10:01 +0000 Received: from localhost (unknown [IPv6:::1]) by mx0.basenordic.cloud (Postfix) with ESMTP id BFFEE8229D1 for ; Wed, 24 Jun 2020 18:09:53 +0000 (UTC) Received: from mx0.basenordic.cloud ([IPv6:::1]) by localhost (winterfell.topphemmelig.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id S3o-uIlW38b7 for ; Wed, 24 Jun 2020 20:09:50 +0200 (CEST) Received: from zimbra.sommerseth.email (zimbra.sommerseth.email [172.16.33.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx0.basenordic.cloud (Postfix) with ESMTPS id 852B1851234 for ; Wed, 24 Jun 2020 20:08:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.sommerseth.email (Postfix) with ESMTP id BC4784172FFE for ; Wed, 24 Jun 2020 20:08:21 +0200 (CEST) Received: from zimbra.sommerseth.email ([127.0.0.1]) by localhost (zimbra.sommerseth.email [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aYFyvBjW2X8t for ; Wed, 24 Jun 2020 20:08:21 +0200 (CEST) Received: from optimus.homebase.sommerseths.net (unknown [10.35.7.3]) by zimbra.sommerseth.email (Postfix) with ESMTPS id 362704172FFC for ; Wed, 24 Jun 2020 20:08:13 +0200 (CEST) From: David Sommerseth To: openvpn-devel@lists.sourceforge.net Date: Wed, 24 Jun 2020 20:07:40 +0200 Message-Id: <20200624180741.426-11-davids@openvpn.net> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200624180741.426-1-davids@openvpn.net> References: <20200624180741.426-1-davids@openvpn.net> MIME-Version: 1.0 X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1jo9qS-00EFCy-1L Subject: [Openvpn-devel] [PATCH 10/11] doc/man: Moved --reneg-* options to its own section 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 The options related to renegotiation of the data channel encryption key is not really a link option. As the renegotiation is encryption related but doesn't really fit into the generic, tls or pkcs11 sections, add it into its own section. Signed-off-by: David Sommerseth --- doc/man-sections/encryption-options.rst | 1 + doc/man-sections/link-options.rst | 47 ---------------------- doc/man-sections/renegotiation.rst | 53 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+), 47 deletions(-) create mode 100644 doc/man-sections/renegotiation.rst diff --git a/doc/man-sections/encryption-options.rst b/doc/man-sections/encryption-options.rst index 5e99c52f..42c80eb8 100644 --- a/doc/man-sections/encryption-options.rst +++ b/doc/man-sections/encryption-options.rst @@ -130,6 +130,7 @@ Generating key material access to this file will be to generate auth tokens that the OpenVPN server will accept as valid. +.. include:: renegotiation.rst .. include:: tls-options.rst .. include:: pkcs11-options.rst diff --git a/doc/man-sections/link-options.rst b/doc/man-sections/link-options.rst index 5f75c5f3..43e33176 100644 --- a/doc/man-sections/link-options.rst +++ b/doc/man-sections/link-options.rst @@ -284,53 +284,6 @@ the local and the remote host. and has been used since version 2.0-beta17. Previous versions used port 5000 as the default. ---reneg-bytes n - Renegotiate data channel key after ``n`` bytes sent or received - (disabled by default with an exception, see below). OpenVPN allows the - lifetime of a key to be expressed as a number of bytes - encrypted/decrypted, a number of packets, or a number of seconds. A key - renegotiation will be forced if any of these three criteria are met by - either peer. - - If using ciphers with cipher block sizes less than 128-bits, - ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly - disabled by setting the value to :code:`0`, but this is - **HIGHLY DISCOURAGED** as this is designed to add some protection against - the SWEET32 attack vector. For more information see the ``--cipher`` - option. - ---reneg-pkts n - Renegotiate data channel key after **n** packets sent and received - (disabled by default). - ---reneg-sec args - Renegotiate data channel key after at most ``max`` seconds - (default :code:`3600`) and at least ``min`` seconds (default is 90% of - ``max`` for servers, and equal to ``max`` for clients). - :: - - reneg-sec max [min] - - The effective ``--reneg-sec`` value used is per session - pseudo-uniform-randomized between ``min`` and ``max``. - - With the default value of :code:`3600` this results in an effective per - session value in the range of :code:`3240`..:code:`3600` seconds for - servers, or just 3600 for clients. - - When using dual-factor authentication, note that this default value may - cause the end user to be challenged to reauthorize once per hour. - - Also, keep in mind that this option can be used on both the client and - server, and whichever uses the lower value will be the one to trigger - the renegotiation. A common mistake is to set ``--reneg-sec`` to a - higher value on either the client or server, while the other side of the - connection is still using the default value of :code:`3600` seconds, - meaning that the renegotiation will still occur once per :code:`3600` - seconds. The solution is to increase --reneg-sec on both the client and - server, or set it to :code:`0` on one side of the connection (to - disable), and to your chosen value on the other side. - --rport port Set TCP/UDP port number or name used by the ``--remote`` option. The port can also be set directly using the ``--remote`` option. diff --git a/doc/man-sections/renegotiation.rst b/doc/man-sections/renegotiation.rst new file mode 100644 index 00000000..aaede4eb --- /dev/null +++ b/doc/man-sections/renegotiation.rst @@ -0,0 +1,53 @@ +Data Channel Renegotiation +-------------------------- + +When running OpenVPN in client/server mode, the data channel will use a +separate ephemeral encryption key which is rotated at regular intervals. + +--reneg-bytes n + Renegotiate data channel key after ``n`` bytes sent or received + (disabled by default with an exception, see below). OpenVPN allows the + lifetime of a key to be expressed as a number of bytes + encrypted/decrypted, a number of packets, or a number of seconds. A key + renegotiation will be forced if any of these three criteria are met by + either peer. + + If using ciphers with cipher block sizes less than 128-bits, + ``--reneg-bytes`` is set to 64MB by default, unless it is explicitly + disabled by setting the value to :code:`0`, but this is + **HIGHLY DISCOURAGED** as this is designed to add some protection against + the SWEET32 attack vector. For more information see the ``--cipher`` + option. + +--reneg-pkts n + Renegotiate data channel key after **n** packets sent and received + (disabled by default). + +--reneg-sec args + Renegotiate data channel key after at most ``max`` seconds + (default :code:`3600`) and at least ``min`` seconds (default is 90% of + ``max`` for servers, and equal to ``max`` for clients). + :: + + reneg-sec max [min] + + The effective ``--reneg-sec`` value used is per session + pseudo-uniform-randomized between ``min`` and ``max``. + + With the default value of :code:`3600` this results in an effective per + session value in the range of :code:`3240`..:code:`3600` seconds for + servers, or just 3600 for clients. + + When using dual-factor authentication, note that this default value may + cause the end user to be challenged to reauthorize once per hour. + + Also, keep in mind that this option can be used on both the client and + server, and whichever uses the lower value will be the one to trigger + the renegotiation. A common mistake is to set ``--reneg-sec`` to a + higher value on either the client or server, while the other side of the + connection is still using the default value of :code:`3600` seconds, + meaning that the renegotiation will still occur once per :code:`3600` + seconds. The solution is to increase --reneg-sec on both the client and + server, or set it to :code:`0` on one side of the connection (to + disable), and to your chosen value on the other side. +