[Openvpn-devel,1/2] Deprecate non TLS mode in OpenVPN

Message ID 20210325000121.10331-1-arne@rfc2549.org
State Superseded
Headers show
Series [Openvpn-devel,1/2] Deprecate non TLS mode in OpenVPN | expand

Commit Message

Arne Schwabe March 24, 2021, 1:01 p.m. UTC
The non-TLS mode is a relict from OpenVPN 1.x or 2.0. When tls mode was
introduce the advantages of TLS over non-tls were small but tls mode
evolved to include a lot more features. (NCP, multipeer, AEAD ciphers to name
a few).

Today VPN that use --secret are mainly used because of its relative easy to
setup and requiring to setup a PKI. This shortcoming of TLS mode should be
addressed now with the peer-fingerprint option.

Signed-off-by: Arne Schwabe <arne@rfc2549.org>
---
 doc/man-sections/protocol-options.rst |  2 +-
 src/openvpn/options.c                 | 12 +++++++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

Comments

tincanteksup March 24, 2021, 1:47 p.m. UTC | #1
I made this change to the wiki:
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?action=diff&version=45
Antonio Quartulli March 24, 2021, 8:49 p.m. UTC | #2
Hi,

On 25/03/2021 01:47, tincanteksup wrote:
> I made this change to the wiki:
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions?action=diff&version=45

I had this discussion with "Pippin_" in #openvpn-meeting:

The change you made is wrong. That part of the wikipage talks about
moving the --genkey argument "secret" from being a standalone "--secret"
to "--gen key secret".

It is unrelated to the "non-TLS mode --secret" that Arne is talking
about in this PATCH.

That change (that was *Actually* made in 2.4) was exactly to remove this
ambiguity.

Since 2.4, you specifu the "secret" argument of "--genkey" by using the
"secret" subargument instead of passing the ambiguous "--secret".

For this reason I believe that this change on the wiki should be reverted.

Regards,
Antonio Quartulli March 24, 2021, 8:59 p.m. UTC | #3
Hi,

On 25/03/2021 08:49, Antonio Quartulli wrote:
> That change (that was *Actually* made in 2.4) was exactly to remove this
> ambiguity.

Forgive my hasty reply. This combination of option is actually
not-supported since 2.5 (in 2.4 we probably only introduced the
deprecation warning).

Regards,
tincanteksup March 25, 2021, 4:46 a.m. UTC | #4
Hi,

On 25/03/2021 07:59, Antonio Quartulli wrote:
> Hi,
> 
> On 25/03/2021 08:49, Antonio Quartulli wrote:
>> That change (that was *Actually* made in 2.4) was exactly to remove this
>> ambiguity.
> 
> Forgive my hasty reply. This combination of option is actually
> not-supported since 2.5 (in 2.4 we probably only introduced the
> deprecation warning).

I think I know what you mean.

Deprecating `--secret` to be `--genkey secret` is on the wiki.
But the change *has* been made in 2.5 not pending for 2.7

Deprecating non-TLS mode VPNs is not on the wiki.

Deprecate non-TLS mode in 2.5
To be removed in 2.7
Replaced by peer-fingerprint option.

If that is correct then I can add "non-TLS mode" to the wiki.
Clear up the mess^D^D^D^D ambiguity ..

How does that sound ?
R
Antonio Quartulli March 25, 2021, 4:52 a.m. UTC | #5
Hi,

On 25/03/2021 16:46, tincanteksup wrote:
> Hi,
> 
> On 25/03/2021 07:59, Antonio Quartulli wrote:
>> Hi,
>>
>> On 25/03/2021 08:49, Antonio Quartulli wrote:
>>> That change (that was *Actually* made in 2.4) was exactly to remove this
>>> ambiguity.
>>
>> Forgive my hasty reply. This combination of option is actually
>> not-supported since 2.5 (in 2.4 we probably only introduced the
>> deprecation warning).
> 
> I think I know what you mean.
> 
> Deprecating `--secret` to be `--genkey secret` is on the wiki.
> But the change *has* been made in 2.5 not pending for 2.7

correct.

> 
> Deprecating non-TLS mode VPNs is not on the wiki.
> 
> Deprecate non-TLS mode in 2.5

this depends on where the patch will be merged. I guess we have to wait
for that.

> To be removed in 2.7

correct

> Replaced by peer-fingerprint option.

not replaced as drop-in, but users of --secret should look at
--peer-fingerprint, yes.

> 
> If that is correct then I can add "non-TLS mode" to the wiki.
> Clear up the mess^D^D^D^D ambiguity ..

I would suggest to wait for the patch to be merged first.
But the summary sounds right.


Cheers,
Matthias Andree March 25, 2021, 8:29 a.m. UTC | #6
Am 25.03.21 um 01:01 schrieb Arne Schwabe:
> The non-TLS mode is a relict from OpenVPN 1.x or 2.0. When tls mode was
> introduce the advantages of TLS over non-tls were small but tls mode
> evolved to include a lot more features. (NCP, multipeer, AEAD ciphers to name
> a few).
>
> Today VPN that use --secret are mainly used because of its relative easy to
> setup and requiring to setup a PKI. This shortcoming of TLS mode should be
> addressed now with the peer-fingerprint option.
>
> Signed-off-by: Arne Schwabe <arne@rfc2549.org>

NAK.

Arne,

I find the reasons you present to withdraw the symmetric non-TLS mode
too weak to justify its deprecation or removal. Yes, TLS-based
configurations may be more feature-rich, but those are not mandatory and
we should not paternalize the users here. Is there a considerable
technical debt to keeping the --secret option?  WireGuard seems to be
becoming quite popular and it provides low-ceremony setups - just as
openvpn --secret does. 

And to make a blunt point, it's not useless just because it's old, else
we should nuke DNS and SMTP.

Regards,
Matthias
Antonio Quartulli March 25, 2021, 8:57 a.m. UTC | #7
Hi,

On 25/03/2021 20:29, Matthias Andree wrote:
> I find the reasons you present to withdraw the symmetric non-TLS mode
> too weak to justify its deprecation or removal. Yes, TLS-based
> configurations may be more feature-rich, but those are not mandatory and
> we should not paternalize the users here. Is there a considerable
> technical debt to keeping the --secret option?  WireGuard seems to be
> becoming quite popular and it provides low-ceremony setups - just as
> openvpn --secret does. 
> 

The new --peer-fingerprint option offers a similar "quick setup" feature
that old users of --secret may want to switch to.

> And to make a blunt point, it's not useless just because it's old, else
> we should nuke DNS and SMTP.

It's not about being old. It's about being insecure.

With --secret (i.e. PSK encryption) there is no key renegotiation/rotation.
This means IVs will be eventually re-used, which translates to
encryption losing part of its strength.

This is unacceptable and users should be prevented from hitting this
situation.

Regards,
Matthias Andree March 25, 2021, 9:07 a.m. UTC | #8
Am 25.03.21 um 20:57 schrieb Antonio Quartulli:
> Hi,
>
> On 25/03/2021 20:29, Matthias Andree wrote:
>> I find the reasons you present to withdraw the symmetric non-TLS mode
>> too weak to justify its deprecation or removal. Yes, TLS-based
>> configurations may be more feature-rich, but those are not mandatory and
>> we should not paternalize the users here. Is there a considerable
>> technical debt to keeping the --secret option?  WireGuard seems to be
>> becoming quite popular and it provides low-ceremony setups - just as
>> openvpn --secret does. 
>>
> The new --peer-fingerprint option offers a similar "quick setup" feature
> that old users of --secret may want to switch to.
>
>> And to make a blunt point, it's not useless just because it's old, else
>> we should nuke DNS and SMTP.
> It's not about being old. It's about being insecure.
>
> With --secret (i.e. PSK encryption) there is no key renegotiation/rotation.
> This means IVs will be eventually re-used, which translates to
> encryption losing part of its strength.
>
> This is unacceptable and users should be prevented from hitting this
> situation.

OK, I withdraw my NAK.
Antonio Quartulli March 25, 2021, 12:07 p.m. UTC | #9
Hi,

On 25/03/2021 01:01, Arne Schwabe wrote:
> The non-TLS mode is a relict from OpenVPN 1.x or 2.0. When tls mode was
> introduce the advantages of TLS over non-tls were small but tls mode
> evolved to include a lot more features. (NCP, multipeer, AEAD ciphers to name
> a few).
> 
> Today VPN that use --secret are mainly used because of its relative easy to
> setup and requiring to setup a PKI. This shortcoming of TLS mode should be
> addressed now with the peer-fingerprint option.
> 
> Signed-off-by: Arne Schwabe <arne@rfc2549.org>

As per the discussion that sparked in this thread, I would suggest
articulating the commit message a bit more to highlight the security
concerns about using --secret and why it's a good idea to get rid of it.

The rest looks good to me.

Cheers,

> ---
>  doc/man-sections/protocol-options.rst |  2 +-
>  src/openvpn/options.c                 | 12 +++++++++++-
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/man-sections/protocol-options.rst b/doc/man-sections/protocol-options.rst
> index 01789e58..4b6928c6 100644
> --- a/doc/man-sections/protocol-options.rst
> +++ b/doc/man-sections/protocol-options.rst
> @@ -235,7 +235,7 @@ configured in a compatible way between both the local and remote side.
>    disables cipher negotiation.
>  
>  --secret args
> -  Enable Static Key encryption mode (non-TLS). Use pre-shared secret
> +  **DEPRECATED** Enable Static Key encryption mode (non-TLS). Use pre-shared secret
>    ``file`` which was generated with ``--genkey``.
>  
>    Valid syntaxes:
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index e52679f0..5b559edf 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -514,7 +514,7 @@ static const char usage_message[] =
>      "\n"
>      "Data Channel Encryption Options (must be compatible between peers):\n"
>      "(These options are meaningful for both Static Key & TLS-mode)\n"
> -    "--secret f [d]  : Enable Static Key encryption mode (non-TLS).\n"
> +    "--secret f [d]  : (DEPRECATED) Enable Static Key encryption mode (non-TLS).\n"
>      "                  Use shared secret file f, generate with --genkey.\n"
>      "                  The optional d parameter controls key directionality.\n"
>      "                  If d is specified, use separate keys for each\n"
> @@ -2564,6 +2564,15 @@ options_postprocess_verify_ce(const struct options *options,
>          msg(M_USAGE, "specify only one of --tls-server, --tls-client, or --secret");
>      }
>  
> +    if (!options->tls_server || !options->tls_client)
> +    {
> +        msg(M_INFO, "DEPRECATION: No tls-client or tls-server option in "
> +                    "configuration detected. OpenVPN 2.7 will remove the "
> +                    "functionality to run a VPN without TLS. "
> +                    "See the examples section in the manual page for "
> +                    "examples of a similar quick setup with peer-fingerprint.");
> +    }
> +
>      if (options->ssl_flags & (SSLF_CLIENT_CERT_NOT_REQUIRED|SSLF_CLIENT_CERT_OPTIONAL))
>      {
>          msg(M_WARN, "WARNING: POTENTIALLY DANGEROUS OPTION "
> @@ -7868,6 +7877,7 @@ add_option(struct options *options,
>      }
>      else if (streq(p[0], "secret") && p[1] && !p[3])
>      {
> +        msg(M_WARN, "DEPRECATED OPTION: The option --secret is deprecated. ");
>          VERIFY_PERMISSION(OPT_P_GENERAL|OPT_P_INLINE);
>          options->shared_secret_file = p[1];
>          options->shared_secret_file_inline = is_inline;
>
Gert Doering March 25, 2021, 8:19 p.m. UTC | #10
Hi,

On Thu, Mar 25, 2021 at 01:01:20AM +0100, Arne Schwabe wrote:
> The non-TLS mode is a relict from OpenVPN 1.x or 2.0. When tls mode was
> introduce the advantages of TLS over non-tls were small but tls mode
> evolved to include a lot more features. (NCP, multipeer, AEAD ciphers to name
> a few).

I think the most prominent benefit is "use of a session key which is
independent of the shared secret", so perfect forward secrecy even if
the secret is lost.  The "features" are a nice benefit, but PFS is 
the truly important part, no?

> Today VPN that use --secret are mainly used because of its relative easy to
> setup and requiring to setup a PKI. This shortcoming of TLS mode should be
> addressed now with the peer-fingerprint option.

This is fine, I'd say.

gert

Patch

diff --git a/doc/man-sections/protocol-options.rst b/doc/man-sections/protocol-options.rst
index 01789e58..4b6928c6 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -235,7 +235,7 @@  configured in a compatible way between both the local and remote side.
   disables cipher negotiation.
 
 --secret args
-  Enable Static Key encryption mode (non-TLS). Use pre-shared secret
+  **DEPRECATED** Enable Static Key encryption mode (non-TLS). Use pre-shared secret
   ``file`` which was generated with ``--genkey``.
 
   Valid syntaxes:
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index e52679f0..5b559edf 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -514,7 +514,7 @@  static const char usage_message[] =
     "\n"
     "Data Channel Encryption Options (must be compatible between peers):\n"
     "(These options are meaningful for both Static Key & TLS-mode)\n"
-    "--secret f [d]  : Enable Static Key encryption mode (non-TLS).\n"
+    "--secret f [d]  : (DEPRECATED) Enable Static Key encryption mode (non-TLS).\n"
     "                  Use shared secret file f, generate with --genkey.\n"
     "                  The optional d parameter controls key directionality.\n"
     "                  If d is specified, use separate keys for each\n"
@@ -2564,6 +2564,15 @@  options_postprocess_verify_ce(const struct options *options,
         msg(M_USAGE, "specify only one of --tls-server, --tls-client, or --secret");
     }
 
+    if (!options->tls_server || !options->tls_client)
+    {
+        msg(M_INFO, "DEPRECATION: No tls-client or tls-server option in "
+                    "configuration detected. OpenVPN 2.7 will remove the "
+                    "functionality to run a VPN without TLS. "
+                    "See the examples section in the manual page for "
+                    "examples of a similar quick setup with peer-fingerprint.");
+    }
+
     if (options->ssl_flags & (SSLF_CLIENT_CERT_NOT_REQUIRED|SSLF_CLIENT_CERT_OPTIONAL))
     {
         msg(M_WARN, "WARNING: POTENTIALLY DANGEROUS OPTION "
@@ -7868,6 +7877,7 @@  add_option(struct options *options,
     }
     else if (streq(p[0], "secret") && p[1] && !p[3])
     {
+        msg(M_WARN, "DEPRECATED OPTION: The option --secret is deprecated. ");
         VERIFY_PERMISSION(OPT_P_GENERAL|OPT_P_INLINE);
         options->shared_secret_file = p[1];
         options->shared_secret_file_inline = is_inline;