[Openvpn-devel,v2,1/4] Implement exit notification via control channel

Message ID 20220520213250.3126372-2-arne@rfc2549.org
State Superseded
Headers show
Series Implement exit notifcation via control channel and temporary AUTH_FAIL | expand

Commit Message

Arne Schwabe May 20, 2022, 9:32 p.m. UTC
Current exit notification relies on data channel messages with specific
prefix. Adding these to new data channel modules (DCO) adds unncessary
complexity for the data for messages that from their idea belong to the
control channel anyway.

This patch adds announcing support for control channel and sending/receving
it. We use the simple EXIT message for this.

Patch V2: add comment about protocol-flags to be not a user visible option,
          fix various grammar mistakes, remove unused argument to
          receive_exit_message
---
 doc/man-sections/client-options.rst |  7 ++++++-
 src/openvpn/crypto.h                |  5 +++++
 src/openvpn/forward.c               |  4 ++++
 src/openvpn/multi.c                 |  5 +++++
 src/openvpn/options.c               | 20 ++++++++++++++++++++
 src/openvpn/push.c                  | 19 +++++++++++++++++++
 src/openvpn/push.h                  |  2 ++
 src/openvpn/sig.c                   | 27 +++++++++++++++++++++++++--
 src/openvpn/ssl.c                   |  3 +++
 src/openvpn/ssl.h                   |  3 +++
 src/openvpn/ssl_ncp.c               |  5 +++++
 11 files changed, 97 insertions(+), 3 deletions(-)

Comments

David Sommerseth June 30, 2022, 8:25 p.m. UTC | #1
On 20/05/2022 23:32, Arne Schwabe wrote:
> Current exit notification relies on data channel messages with specific
> prefix. Adding these to new data channel modules (DCO) adds unncessary
> complexity for the data for messages that from their idea belong to the
> control channel anyway.
> 
> This patch adds announcing support for control channel and sending/receving
> it. We use the simple EXIT message for this.
> 
> Patch V2: add comment about protocol-flags to be not a user visible option,
>            fix various grammar mistakes, remove unused argument to
>            receive_exit_message
> ---
>   doc/man-sections/client-options.rst |  7 ++++++-
>   src/openvpn/crypto.h                |  5 +++++
>   src/openvpn/forward.c               |  4 ++++
>   src/openvpn/multi.c                 |  5 +++++
>   src/openvpn/options.c               | 20 ++++++++++++++++++++
>   src/openvpn/push.c                  | 19 +++++++++++++++++++
>   src/openvpn/push.h                  |  2 ++
>   src/openvpn/sig.c                   | 27 +++++++++++++++++++++++++--
>   src/openvpn/ssl.c                   |  3 +++
>   src/openvpn/ssl.h                   |  3 +++
>   src/openvpn/ssl_ncp.c               |  5 +++++
>   11 files changed, 97 insertions(+), 3 deletions(-)
> 

[...snip...]

> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 9ff384d09..427d58392 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -8326,6 +8326,8 @@ add_option(struct options *options,
>       }
>       else if (streq(p[0], "key-derivation") && p[1])
>       {
> +        /* NCP only option that is pushed by the server to enable EKM,
> +         * should not be used by normal users in config files*/

This part seems unrelated.

>           VERIFY_PERMISSION(OPT_P_NCP)
>   #ifdef HAVE_EXPORT_KEYING_MATERIAL
>           if (streq(p[1], "tls-ekm"))
> @@ -8338,6 +8340,24 @@ add_option(struct options *options,
>               msg(msglevel, "Unknown key-derivation method %s", p[1]);
>           }
>       }
> +    else if (streq(p[0], "protocol-flags") && p[1])
> +    {
> +        /* NCP only option that is pushed by the server to enable protocol
> +         * features that are negotiated, should not be used by normal users
> +         * in config files */
> +        VERIFY_PERMISSION(OPT_P_NCP)
> +        for (size_t j = 1; j < MAX_PARMS && p[j] != NULL; j++)
> +        {
> +            if (streq(p[j], "cc-exit"))
> +            {
> +                options->data_channel_crypto_flags |= CO_USE_CC_EXIT_NOTIFY;
> +            }
> +            else
> +            {
> +                msg(msglevel, "Unknown protocol-flags flag: %s", p[j]);
> +            }
> +        }
> +    }

Isn't it possible to do this by pushing IV_PROTO from the server to the 
client?  That could be more compact than adding 22 more bytes to the 
PUSH_REPLY while IV_PROTO takes less "space" on the wire to indicate a 
feature.  Plus the client already sends the IV_PROTO with the 
CC_EXIT_NOTIFY feature flag to the server with this patch.

The rest of the code otherwise looks reasonable with the current "option 
approach".  The client also sends the IV_PROTO_CC_EXIT_NOTIFY flag to 
the server, as expected.
Arne Schwabe June 30, 2022, 10:42 p.m. UTC | #2
Am 30.06.2022 um 22:25 schrieb David Sommerseth:
> On 20/05/2022 23:32, Arne Schwabe wrote:
>> Current exit notification relies on data channel messages with specific
>> prefix. Adding these to new data channel modules (DCO) adds unncessary
>> complexity for the data for messages that from their idea belong to the
>> control channel anyway.
>>
>> This patch adds announcing support for control channel and 
>> sending/receving
>> it. We use the simple EXIT message for this.
>>
>> Patch V2: add comment about protocol-flags to be not a user visible 
>> option,
>>            fix various grammar mistakes, remove unused argument to
>>            receive_exit_message
>> ---
>>   doc/man-sections/client-options.rst |  7 ++++++-
>>   src/openvpn/crypto.h                |  5 +++++
>>   src/openvpn/forward.c               |  4 ++++
>>   src/openvpn/multi.c                 |  5 +++++
>>   src/openvpn/options.c               | 20 ++++++++++++++++++++
>>   src/openvpn/push.c                  | 19 +++++++++++++++++++
>>   src/openvpn/push.h                  |  2 ++
>>   src/openvpn/sig.c                   | 27 +++++++++++++++++++++++++--
>>   src/openvpn/ssl.c                   |  3 +++
>>   src/openvpn/ssl.h                   |  3 +++
>>   src/openvpn/ssl_ncp.c               |  5 +++++
>>   11 files changed, 97 insertions(+), 3 deletions(-)
>>
>
> [...snip...]
>
>> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
>> index 9ff384d09..427d58392 100644
>> --- a/src/openvpn/options.c
>> +++ b/src/openvpn/options.c
>> @@ -8326,6 +8326,8 @@ add_option(struct options *options,
>>       }
>>       else if (streq(p[0], "key-derivation") && p[1])
>>       {
>> +        /* NCP only option that is pushed by the server to enable EKM,
>> +         * should not be used by normal users in config files*/
>
> This part seems unrelated.


Yes. But basically adding that documentation for the other push only 
protocol felt related and small enough to not warrant an extra patch.

>
>>           VERIFY_PERMISSION(OPT_P_NCP)
>>   #ifdef HAVE_EXPORT_KEYING_MATERIAL
>>           if (streq(p[1], "tls-ekm"))
>> @@ -8338,6 +8340,24 @@ add_option(struct options *options,
>>               msg(msglevel, "Unknown key-derivation method %s", p[1]);
>>           }
>>       }
>> +    else if (streq(p[0], "protocol-flags") && p[1])
>> +    {
>> +        /* NCP only option that is pushed by the server to enable 
>> protocol
>> +         * features that are negotiated, should not be used by 
>> normal users
>> +         * in config files */
>> +        VERIFY_PERMISSION(OPT_P_NCP)
>> +        for (size_t j = 1; j < MAX_PARMS && p[j] != NULL; j++)
>> +        {
>> +            if (streq(p[j], "cc-exit"))
>> +            {
>> +                options->data_channel_crypto_flags |= 
>> CO_USE_CC_EXIT_NOTIFY;
>> +            }
>> +            else
>> +            {
>> +                msg(msglevel, "Unknown protocol-flags flag: %s", p[j]);
>> +            }
>> +        }
>> +    }
>
> Isn't it possible to do this by pushing IV_PROTO from the server to 
> the client?  That could be more compact than adding 22 more bytes to 
> the PUSH_REPLY while IV_PROTO takes less "space" on the wire to 
> indicate a feature.  Plus the client already sends the IV_PROTO with 
> the CC_EXIT_NOTIFY feature flag to the server with this patch.

The whole peer info field is empty and happens at a very different time 
before even looking at ccd/connect-script/deferred password aut etc that 
might influence what is pushed to a client. So pushing configuration at 
a completely different time that is extremely early is just adding a lot 
of extra complexity. We do it this way in p2p mode by comparing IV_PROTO 
values from two clients but that p2p mode has nothing after the initial 
handshake and will consider a session established after the initial 
handshake.

Space in push reply is not really a big concern as push replies don't 
have the tight limit that the packet the IV_PROTO contains has. If we 
wanted to have something that is more space efficient, we could change  
protocol-flags cc-exit feat2 feat3 to proto-flgs 82734 like IV_PROTO. 
Basically if I had been a bit more forwarding looking we would now have 
protocol-flags ekm cc-exit instead of key-derivation ekm and 
protocol-flags cc-exit

>
> The rest of the code otherwise looks reasonable with the current 
> "option approach".  The client also sends the IV_PROTO_CC_EXIT_NOTIFY 
> flag to the server, as expected.
>
>
Heiko Hund Aug. 18, 2022, 2:38 p.m. UTC | #3
On Freitag, 1. Juli 2022 00:42:55 CEST Arne Schwabe wrote:
> Basically if I had been a bit more forwarding looking we would now have
> protocol-flags ekm cc-exit instead of key-derivation ekm and
> protocol-flags cc-exit

Then maybe also add support for handling ekm via --protocol-flags and 
deprecate/remove sending --key-derivation?
Heiko Hund Aug. 18, 2022, 2:39 p.m. UTC | #4
Patch and thus series doesn't apply anymore, in addition to eventual changes 
also please rebase.

On Freitag, 20. Mai 2022 23:32:47 CEST Arne Schwabe wrote:
> +  If both server and client support sending this message using the control
> +  channel, the message will be sent as control-channel message. Otherwise
> +  the message is sent as data-channel message, which will be ignored by
> +  data-channel offloaded peers.
> +
>    The **n** parameter (default :code:`1` if not present) controls the
>    maximum number of attempts that the client will try to resend the exit
> -  notification message.
> +  notification message if messages are sent in data-channel mode.

You don't need the "n" for the control channel exit notification because of 
the reliability layer, right?!

> +    if (proto & IV_PROTO_CC_EXIT_NOTIFY)
> +    {
> +        o->data_channel_crypto_flags |= CO_USE_CC_EXIT_NOTIFY;
> +    }

The flags variable is named confusingly now. Is renaming an option?

>  static void
>  process_explicit_exit_notification_init(struct context *c)
>  {
>      msg(M_INFO, "SIGTERM received, sending exit notification to peer");
>      event_timeout_init(&c->c2.explicit_exit_notification_interval, 1, 0);
>      reset_coarse_timers(c);

Do we need to timer event if !cc_exit_notify_enabled(c)?
Arne Schwabe Aug. 18, 2022, 7:48 p.m. UTC | #5
Am 18.08.22 um 16:38 schrieb Heiko Hund:
> On Freitag, 1. Juli 2022 00:42:55 CEST Arne Schwabe wrote:
>> Basically if I had been a bit more forwarding looking we would now have
>> protocol-flags ekm cc-exit instead of key-derivation ekm and
>> protocol-flags cc-exit
> 
> Then maybe also add support for handling ekm via --protocol-flags and
> deprecate/remove sending --key-derivation?
> 

Yeah, I can do that in follow up patch to add ekm as accepted in 
protocol-flags

Arne
Arne Schwabe Aug. 18, 2022, 7:49 p.m. UTC | #6
Am 18.08.22 um 16:39 schrieb Heiko Hund:
> Patch and thus series doesn't apply anymore, in addition to eventual changes
> also please rebase.
> 
> On Freitag, 20. Mai 2022 23:32:47 CEST Arne Schwabe wrote:
>> +  If both server and client support sending this message using the control
>> +  channel, the message will be sent as control-channel message. Otherwise
>> +  the message is sent as data-channel message, which will be ignored by
>> +  data-channel offloaded peers.
>> +
>>     The **n** parameter (default :code:`1` if not present) controls the
>>     maximum number of attempts that the client will try to resend the exit
>> -  notification message.
>> +  notification message if messages are sent in data-channel mode.
> 
> You don't need the "n" for the control channel exit notification because of
> the reliability layer, right?!
> 
>> +    if (proto & IV_PROTO_CC_EXIT_NOTIFY)
>> +    {
>> +        o->data_channel_crypto_flags |= CO_USE_CC_EXIT_NOTIFY;
>> +    }
> 
> The flags variable is named confusingly now. Is renaming an option?

Yes it is. But it is also still fitting, because it is affecting data 
channel to not send it via this :P

> 
>>   static void
>>   process_explicit_exit_notification_init(struct context *c)
>>   {
>>       msg(M_INFO, "SIGTERM received, sending exit notification to peer");
>>       event_timeout_init(&c->c2.explicit_exit_notification_interval, 1, 0);
>>       reset_coarse_timers(c);
> 
> Do we need to timer event if !cc_exit_notify_enabled(c)?
> 

Iirc yes. The timer will will trigger the dealyed exit.

Arne

Patch

diff --git a/doc/man-sections/client-options.rst b/doc/man-sections/client-options.rst
index 8e0e4f18a..5a906895b 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -220,9 +220,14 @@  configuration.
   immediately close its client instance object rather than waiting for a
   timeout.
 
+  If both server and client support sending this message using the control
+  channel, the message will be sent as control-channel message. Otherwise
+  the message is sent as data-channel message, which will be ignored by
+  data-channel offloaded peers.
+
   The **n** parameter (default :code:`1` if not present) controls the
   maximum number of attempts that the client will try to resend the exit
-  notification message.
+  notification message if messages are sent in data-channel mode.
 
   In UDP server mode, send :code:`RESTART` control channel command to
   connected clients. The ``n`` parameter (default :code:`1` if not present)
diff --git a/src/openvpn/crypto.h b/src/openvpn/crypto.h
index 98e2c7664..5ea889081 100644
--- a/src/openvpn/crypto.h
+++ b/src/openvpn/crypto.h
@@ -264,6 +264,11 @@  struct crypto_options
     /**< Bit-flag indicating that we do not allow clients that do
      * not support resending the wrapped client key (WKc) with the
      * third packet of the three-way handshake */
+#define CO_USE_CC_EXIT_NOTIFY       (1<<6)
+    /**< Bit-flag indicating that explicit exit notifies should be
+     * sent via the control channel instead of using an OCC message
+     */
+
     unsigned int flags;         /**< Bit-flags determining behavior of
                                  *   security operation functions. */
 };
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 6afe152b4..4fb3a20d7 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -241,6 +241,10 @@  check_incoming_control_channel(struct context *c)
         {
             receive_auth_pending(c, &buf);
         }
+        else if (buf_string_match_head_str(&buf, "EXIT"))
+        {
+            receive_exit_message(c);
+        }
         else
         {
             msg(D_PUSH_ERRORS, "WARNING: Received unknown control message: %s", BSTR(&buf));
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index ba2f6d581..e7c99f813 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1777,6 +1777,11 @@  multi_client_set_protocol_options(struct context *c)
     }
 #endif
 
+    if (proto & IV_PROTO_CC_EXIT_NOTIFY)
+    {
+        o->data_channel_crypto_flags |= CO_USE_CC_EXIT_NOTIFY;
+    }
+
     /* Select cipher if client supports Negotiable Crypto Parameters */
 
     /* if we have already created our key, we cannot *change* our own
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 9ff384d09..427d58392 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -8326,6 +8326,8 @@  add_option(struct options *options,
     }
     else if (streq(p[0], "key-derivation") && p[1])
     {
+        /* NCP only option that is pushed by the server to enable EKM,
+         * should not be used by normal users in config files*/
         VERIFY_PERMISSION(OPT_P_NCP)
 #ifdef HAVE_EXPORT_KEYING_MATERIAL
         if (streq(p[1], "tls-ekm"))
@@ -8338,6 +8340,24 @@  add_option(struct options *options,
             msg(msglevel, "Unknown key-derivation method %s", p[1]);
         }
     }
+    else if (streq(p[0], "protocol-flags") && p[1])
+    {
+        /* NCP only option that is pushed by the server to enable protocol
+         * features that are negotiated, should not be used by normal users
+         * in config files */
+        VERIFY_PERMISSION(OPT_P_NCP)
+        for (size_t j = 1; j < MAX_PARMS && p[j] != NULL; j++)
+        {
+            if (streq(p[j], "cc-exit"))
+            {
+                options->data_channel_crypto_flags |= CO_USE_CC_EXIT_NOTIFY;
+            }
+            else
+            {
+                msg(msglevel, "Unknown protocol-flags flag: %s", p[j]);
+            }
+        }
+    }
     else if (streq(p[0], "prng") && p[1] && !p[3])
     {
         msg(M_WARN, "NOTICE: --prng option ignored (SSL library PRNG is used)");
diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 70fd1c3ce..fa0def7f8 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -176,6 +176,21 @@  server_pushed_signal(struct context *c, const struct buffer *buffer, const bool
     }
 }
 
+void
+receive_exit_message(struct context *c)
+{
+    dmsg(D_STREAM_ERRORS, "Exit message received by peer");
+    c->sig->signal_received = SIGTERM;
+    c->sig->signal_text = "remote-exit";
+#ifdef ENABLE_MANAGEMENT
+    if (management)
+    {
+        management_notify(management, "info", c->sig->signal_text, "EXIT");
+    }
+#endif
+}
+
+
 void
 server_pushed_info(struct context *c, const struct buffer *buffer,
                    const int adv)
@@ -604,6 +619,10 @@  prepare_push_reply(struct context *c, struct gc_arena *gc,
     {
         push_option_fmt(gc, push_list, M_USAGE, "key-derivation tls-ekm");
     }
+    if (o->data_channel_crypto_flags & CO_USE_CC_EXIT_NOTIFY)
+    {
+        push_option_fmt(gc, push_list, M_USAGE, "protocol-flags cc-exit");
+    }
     return true;
 }
 
diff --git a/src/openvpn/push.h b/src/openvpn/push.h
index 62fad4a14..7138055a7 100644
--- a/src/openvpn/push.h
+++ b/src/openvpn/push.h
@@ -48,6 +48,8 @@  void receive_auth_failed(struct context *c, const struct buffer *buffer);
 
 void server_pushed_signal(struct context *c, const struct buffer *buffer, const bool restart, const int adv);
 
+void receive_exit_message(struct context *c);
+
 void server_pushed_info(struct context *c, const struct buffer *buffer,
                         const int adv);
 
diff --git a/src/openvpn/sig.c b/src/openvpn/sig.c
index e06edd216..d6683d2d1 100644
--- a/src/openvpn/sig.c
+++ b/src/openvpn/sig.c
@@ -321,20 +321,43 @@  print_status(const struct context *c, struct status_output *so)
     gc_free(&gc);
 }
 
+
+/* Small helper function to determine if we should send the exit notification
+ * via control channel */
+static inline bool
+cc_exit_notify_enabled(struct context *c)
+{
+    /* Check if we have TLS active at all */
+    if (!c->c2.tls_multi)
+    {
+        return false;
+    }
+
+    const struct key_state *ks = get_primary_key(c->c2.tls_multi);
+    return (ks->crypto_options.flags & CO_USE_CC_EXIT_NOTIFY);
+}
+
 /*
  * Handle the triggering and time-wait of explicit
  * exit notification.
  */
-
 static void
 process_explicit_exit_notification_init(struct context *c)
 {
     msg(M_INFO, "SIGTERM received, sending exit notification to peer");
     event_timeout_init(&c->c2.explicit_exit_notification_interval, 1, 0);
     reset_coarse_timers(c);
+
     signal_reset(c->sig);
     halt_non_edge_triggered_signals();
     c->c2.explicit_exit_notification_time_wait = now;
+
+    /* Check if we are in TLS mode and should send the notification via data
+     * channel */
+    if (cc_exit_notify_enabled(c))
+    {
+        send_control_channel_string(c, "EXIT", D_PUSH);
+    }
 }
 
 void
@@ -351,7 +374,7 @@  process_explicit_exit_notification_timer_wakeup(struct context *c)
             c->sig->signal_received = SIGTERM;
             c->sig->signal_text = "exit-with-notification";
         }
-        else
+        else if (!cc_exit_notify_enabled(c))
         {
             c->c2.occ_op = OCC_EXIT;
         }
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 61dea996d..4506b7504 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -1940,6 +1940,9 @@  push_peer_info(struct buffer *buf, struct tls_session *session)
         /* support for P_DATA_V2 */
         int iv_proto = IV_PROTO_DATA_V2;
 
+        /* support for exit notify via control channel */
+        iv_proto |= IV_PROTO_CC_EXIT_NOTIFY;
+
         /* support for receiving push_reply before sending
          * push request, also signal that the client wants
          * to get push-reply messages without without requiring a round
diff --git a/src/openvpn/ssl.h b/src/openvpn/ssl.h
index 0ba86d3e6..1b8b736b9 100644
--- a/src/openvpn/ssl.h
+++ b/src/openvpn/ssl.h
@@ -93,6 +93,9 @@ 
  * result. */
 #define IV_PROTO_NCP_P2P         (1<<5)
 
+/** Support for explicit exit notify via control channel */
+#define IV_PROTO_CC_EXIT_NOTIFY  (1<<7)
+
 /* Default field in X509 to be username */
 #define X509_USERNAME_FIELD_DEFAULT "CN"
 
diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
index 5d7e6dd38..4a083e247 100644
--- a/src/openvpn/ssl_ncp.c
+++ b/src/openvpn/ssl_ncp.c
@@ -419,6 +419,11 @@  p2p_ncp_set_options(struct tls_multi *multi, struct tls_session *session)
         multi->peer_id = 0x76706e; /* 'v' 'p' 'n' */
     }
 
+    if (iv_proto_peer & IV_PROTO_CC_EXIT_NOTIFY)
+    {
+        session->opt->crypto_flags |= CO_USE_CC_EXIT_NOTIFY;
+    }
+
 #if defined(HAVE_EXPORT_KEYING_MATERIAL)
     if (iv_proto_peer & IV_PROTO_TLS_KEY_EXPORT)
     {