From patchwork Wed Jun 24 08:07:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Sommerseth X-Patchwork-Id: 1164 Return-Path: Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director11.mail.ord1d.rsapps.net ([172.31.255.6]) by backend30.mail.ord1d.rsapps.net with LMTP id yMFJHRGX815yLwAAIUCqbw for ; Wed, 24 Jun 2020 14:10:25 -0400 Received: from proxy9.mail.iad3b.rsapps.net ([172.31.255.6]) by director11.mail.ord1d.rsapps.net with LMTP id QOykGhGX817sVgAAvGGmqA ; Wed, 24 Jun 2020 14:10:25 -0400 Received: from smtp1.gate.iad3b ([172.31.255.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy9.mail.iad3b.rsapps.net with LMTP id qJduARCX816kCwAAC4PSzw ; Wed, 24 Jun 2020 14:10:25 -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: smtp1.gate.iad3b.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: f855993a-b645-11ea-9f00-5254008fd675-1-1 Received: from [216.105.38.7] ([216.105.38.7:51480] helo=lists.sourceforge.net) by smtp1.gate.iad3b.rsapps.net (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id 25/41-31734-E0793FE5; Wed, 24 Jun 2020 14:10:23 -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 1jo9qE-0001UP-4o; Wed, 24 Jun 2020 18:09:46 +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 1jo9qC-0001U9-Ld for openvpn-devel@lists.sourceforge.net; Wed, 24 Jun 2020 18:09:44 +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=sWbxxiim6iDh9L9s/rUtcWb1xplQO5Zv2+88gV5tHvo=; b=JY9tn5eO1BR/Fwifn7FsPrRKvi jrHzaew5kyvnTUAVDaI7F2n0VXaby7AUcp8hck99zzUglX6tI6Vb0OUhdCEwPWdYQdkAHLLkarB7s OLU9DU+UHVUAW9Cf8iydht5UIb5u8/L/SmyiTgBTYKBjms/zCON2VqjVMUiG7Qdw9fvw=; 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=sWbxxiim6iDh9L9s/rUtcWb1xplQO5Zv2+88gV5tHvo=; b=Z0d57BFOv8jD4fPi9sFHmFJrIs rqO3fjtMKwirCXjBUijftij8tYZCmgtAc5SZKf5IgvrgONdiGw4DGZ4qkhY5LboEk9awFO+hpPJL1 pzXvoS4ryUDn+G7N41wbR4DmA+F6FVc0fSa4Ss3TAL2xL4WvL3DEpbovIhhBXpGQ6+Fw=; Received: from mx0.basenordic.cloud ([185.212.44.139]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1jo9qA-00GslV-La for openvpn-devel@lists.sourceforge.net; Wed, 24 Jun 2020 18:09:44 +0000 Received: from localhost (unknown [IPv6:::1]) by mx0.basenordic.cloud (Postfix) with ESMTP id 3087382F9F2 for ; Wed, 24 Jun 2020 18:09:29 +0000 (UTC) Received: from mx0.basenordic.cloud ([IPv6:::1]) by localhost (winterfell.topphemmelig.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id abU_qdtwezIf for ; Wed, 24 Jun 2020 20:09:24 +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 53E18837AB7 for ; Wed, 24 Jun 2020 20:08:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.sommerseth.email (Postfix) with ESMTP id 8D58E4172FFC for ; Wed, 24 Jun 2020 20:08:11 +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 DX5FfgX8MKje for ; Wed, 24 Jun 2020 20:08:11 +0200 (CEST) Received: from optimus.homebase.sommerseths.net (unknown [10.35.7.3]) by zimbra.sommerseth.email (Postfix) with ESMTPS id B95094172FFF for ; Wed, 24 Jun 2020 20:08:07 +0200 (CEST) From: David Sommerseth To: openvpn-devel@lists.sourceforge.net Date: Wed, 24 Jun 2020 20:07:34 +0200 Message-Id: <20200624180741.426-5-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: 1jo9qA-00GslV-La Subject: [Openvpn-devel] [PATCH 04/11] doc/man: Remove unsupported options in OpenVPN 2.5 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 This removes the options from the man page which is enlisted as deprecated options in OpenVPN 2.5. To provide some history, a short summary of why they were removed has been put into a new file which is included into its own "UNSUPPORTED OPTIONS" section in the man page. Signed-off-by: David Sommerseth --- doc/openvpn.8.rst | 144 +----------------------------------- doc/unsupported-options.rst | 33 +++++++++ 2 files changed, 35 insertions(+), 142 deletions(-) create mode 100644 doc/unsupported-options.rst diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst index fc3ecdb8..713cd309 100644 --- a/doc/openvpn.8.rst +++ b/doc/openvpn.8.rst @@ -454,9 +454,7 @@ Tunnel Options: the client's tun interface always points to the local endpoint of the server's tun interface. This mode allocates a single IP address per connecting client. Only use when none of the connecting clients are - Windows systems. This mode is functionally equivalent to the - ``--ifconfig-pool-linear`` directive which is available in OpenVPN 2.0, - is deprecated and will be removed in OpenVPN 2.5 + Windows systems. :code:`subnet` Use a subnet rather than a point-to-point topology by @@ -2184,17 +2182,6 @@ fast hardware. SSL/TLS authentication must be used in this mode. receive the given IP address. If you want guaranteed assignment, use ``--ifconfig-push`` ---ifconfig-pool-linear - **DEPRECATED** This option will be removed in OpenVPN 2.5 - - Modifies the ``--ifconfig-pool`` directive to allocate individual TUN - interface addresses for clients rather than /30 subnets. - - *NOTE:* This option is incompatible with Windows clients. - - This option is deprecated, and should be replaced with ``--topology - p2p`` which is functionally equivalent. - --ifconfig-push args Push virtual IP endpoints for client tunnel, overriding the ``--ifconfig-pool`` dynamic allocation. @@ -2668,17 +2655,6 @@ fast hardware. SSL/TLS authentication must be used in this mode. authentication module/script MUST have logic to detect this condition and respond accordingly. ---client-cert-not-required - **DEPRECATED** This option will be removed in OpenVPN 2.5 - - Don't require client certificate, client will authenticate using - username/password only. Be aware that using this directive is less - secure than requiring certificates from all clients. - - **Please note:** This is replaced by ``--verify-client-cert`` which - allows for more flexibility. The option ``--verify-client-cert none`` is - functionally equivalent to ``--client-cert-not-required`` - --verify-client-cert mode Specify whether the client is required to supply a valid certificate. @@ -3178,41 +3154,6 @@ These options are meaningful for both Static & TLS-negotiated key modes ``--show-engines`` standalone option to list the crypto engines which are supported by OpenSSL. ---no-replay - **DEPRECATED** This option will be removed in OpenVPN 2.5. - - (Advanced) Disable OpenVPN's protection against replay attacks. Don't - use this option unless you are prepared to make a tradeoff of greater - efficiency in exchange for less security. - - OpenVPN provides datagram replay protection by default. - - Replay protection is accomplished by tagging each outgoing datagram with - an identifier that is guaranteed to be unique for the key being used. - The peer that receives the datagram will check for the uniqueness of the - identifier. If the identifier was already received in a previous - datagram, OpenVPN will drop the packet. Replay protection is important - to defeat attacks such as a SYN flood attack, where the attacker listens - in the wire, intercepts a TCP SYN packet (identifying it by the context - in which it occurs in relation to other packets), then floods the - receiving peer with copies of this packet. - - OpenVPN's replay protection is implemented in slightly different ways, - depending on the key management mode you have selected. - - In Static Key mode or when using an CFB or OFB mode cipher, OpenVPN uses - a 64 bit unique identifier that combines a time stamp with an - incrementing sequence number. - - When using TLS mode for key exchange and a CBC cipher mode, OpenVPN uses - only a 32 bit sequence number without a time stamp, since OpenVPN can - guarantee the uniqueness of this value for each key. As in IPSec, if the - sequence number is close to wrapping back to zero, OpenVPN will trigger - a new key exchange. - - To check for replays, OpenVPN uses the *sliding window* algorithm used - by IPSec. - --replay-window args Modify the replay protection sliding-window size and time window. @@ -3311,27 +3252,6 @@ These options are meaningful for both Static & TLS-negotiated key modes default) and you are using either ``--secret`` (shared-secret key mode) or TLS mode with ``--tls-auth``. ---no-iv - **DEPRECATED** This option will be removed in OpenVPN 2.5. - - (Advanced) Disable OpenVPN's use of IV (cipher initialization vector). - Don't use this option unless you are prepared to make a tradeoff of - greater efficiency in exchange for less security. - - OpenVPN uses an IV by default, and requires it for CFB and OFB cipher - modes (which are totally insecure without it). Using an IV is important - for security when multiple messages are being encrypted/decrypted with - the same key. - - IV is implemented differently depending on the cipher mode used. - - In CBC mode, OpenVPN uses a pseudo-random IV for each packet. - - In CFB/OFB mode, OpenVPN uses a unique sequence number and time stamp as - the IV. In fact, in CFB/OFB mode, OpenVPN uses a datagram space-saving - optimization that uses the unique identifier for datagram replay - protection as the IV. - --use-prediction-resistance Enable prediction resistance on mbed TLS's RNG. @@ -3635,39 +3555,6 @@ certificates and keys: https://github.com/OpenVPN/easy-rsa The thumbprint hex string can easily be copy-and-pasted from the Windows Certificate Store GUI. ---key-method m - **DEPRECATED** This option will be removed in OpenVPN 2.5 - - Use data channel key negotiation method ``m``. The key method must match - on both sides of the connection. - - After OpenVPN negotiates a TLS session, a new set of keys for protecting - the tunnel data channel is generated and exchanged over the TLS session. - - In method :code:`1` (the default for OpenVPN 1.x), both sides generate - random encrypt and HMAC-send keys which are forwarded to the other host - over the TLS channel. Method :code:`1` is **deprecated in OpenVPN 2.4**, - and **will be removed in OpenVPN 2.5**. - - In method :code:`2`, (the default for OpenVPN 2.0) the client generates - a random key. Both client and server also generate some random seed - material. All key source material is exchanged over the TLS channel. The - actual keys are generated using the TLS PRF function, taking source - entropy from both client and server. Method :code:`2` is designed to - closely parallel the key generation process used by TLS 1.0. - - Note that in TLS mode, two separate levels of keying occur: - - (1) The TLS connection is initially negotiated, with both sides of the - connection producing certificates and verifying the certificate (or - other authentication info provided) of the other side. The - ``--key-method`` parameter has no effect on this process. - - (2) After the TLS connection is established, the tunnel session keys are - separately negotiated over the existing secure TLS channel. Here, - ``--key-method`` determines the derivation of the tunnel session keys. - - *WARNING:* ``--tls-ciphers`` and ``--tls-ciphersuites`` These options are expert features, which - if used correctly - can improve the security of your VPN connection. But it is also easy to @@ -4175,34 +4062,6 @@ certificates and keys: https://github.com/OpenVPN/easy-rsa :code:`X509__=`. Multiple ``--x509-track`` options can be defined to track multiple attributes. ---ns-cert-type args - **DEPRECATED** This option will be removed in OpenVPN 2.5. Use the more - modern equivalent ``--remote-cert-tls`` instead. This option will be - removed in OpenVPN 2.5. - - Valid syntax: - :: - - ns-cert-type client | server - - Require that peer certificate was signed with an explicit ``nsCertType`` - designation of :code:`client` or :code:`server`. - - This is a useful security option for clients, to ensure that the host - they connect with is a designated server. - - See the easy-rsa/build-key-server script for an example of how to - generate a certificate with the ``nsCertType`` field set to "server". - - If the server certificate's nsCertType field is set to :code:`server`, - then the clients can verify this with :code:`--ns-cert-type server`. - - This is an important security precaution to protect against a - man-in-the-middle attack where an authorized client attempts to connect - to another client by impersonating the server. The attack is easily - prevented by having clients verify the server certificate using any one - of ``--ns-cert-type``, ``--verify-x509-name`` or ``--tls-verify``. - --remote-cert-ku key-usage Require that peer certificate was signed with an explicit ``key-usage``. @@ -4911,6 +4770,7 @@ well (except for **--topology** , which has no effect on IPv6). iroute-ipv6 ipv6addr/bits +.. include:: unsupported-options.rst SCRIPTING AND ENVIRONMENTAL VARIABLES ===================================== diff --git a/doc/unsupported-options.rst b/doc/unsupported-options.rst new file mode 100644 index 00000000..ae7c1bcc --- /dev/null +++ b/doc/unsupported-options.rst @@ -0,0 +1,33 @@ + +UNSUPPORTED OPTIONS +=================== + +Options listed in this section has been removed from OpenVPN and is no +longer supported + +--client-cert-not-required + Removed in OpenVPN 2.5. This should be replaxed with + ``--verify-client-cert none``. + +--ifconfig-pool-linear + Removed in OpenVPN 2.5. This should be replaced with ``--topology p2p``. + +--key-method + Removed in OpenVPN 2.5. This option should not be used, as using the old + ``key-method`` weakens the VPN tunnel security. The old ``key-method`` + was also only needed when the remote side was older than OpenVPN 2.0. + +--no-iv + Removed in OpenVPN 2.5. This option should not be used as it weakens the + VPN tunnel security. + +--no-reply + Removed in OpenVPN 2.5. This option should not be used as it weakens the + VPN tunnel security. + +--ns-cert-type + Removed in OpenVPN 2.5. The ``nsCertType`` field is no longer supported + in recent SSL/TLS libraries. If your certificates does not include *key + usage* and *extended key usage* fields, they must be upgraded and the + ``--remote-cert-tls`` option should be used instead. +