1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
From 227fbc117d58a87465804f7b2a5cd95ef1b94da6 Mon Sep 17 00:00:00 2001
From: Arne Schwabe <arne@rfc2549.org>
Date: Sun, 28 Mar 2021 14:02:41 +0200
Subject: [PATCH] Fix condition to generate session keys
When OpenVPN sees a new (SSL) connection via HARD_RESET or SOFT_RESET with
the same port/ip as an existing session, it will give it the slot of the
renegotiation session (TM_UNTRUSTED). And when the authentication
succeeds it will replace the current session. In the case of a SOFT_RESET
this a renegotiation and we will generated data channel keys at the of
key_method_2_write function as key-id > 0.
For a HARD RESET the key-id is 0. Since we already have gone through
connect stages and set context_auth to CAS_SUCCEEDED, we don't
call all the connect stages again, and therefore also never call
multi_client_generate_tls_keys for this session.
This commit changes postponing the key generation to be done only if
the multi_connect has not yet been finished.
Patch V2: Explain better in the commit message why this change is done.
This is "sort of" a backport of commit a005044be9ca, except that the
master commit only got 1 of 3 hunks from the mailing list patch merged
while release/2.5 needs all 3. So this is exactly the patch as it was
sent to the list, URL below.
Trac: #1316
Signed-off-by: Arne Schwabe <arne@rfc2549.org>
Acked-by: Antonio Quartulli <antonio@openvpn.net>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20210328120241.27605-2-arne@rfc2549.org>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg21873.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
---
src/openvpn/ssl.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index d7494c2b3e..8359748b9b 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2295,7 +2295,8 @@ push_peer_info(struct buffer *buf, struct tls_session *session)
* to the TLS control channel (cleartext).
*/
static bool
-key_method_2_write(struct buffer *buf, struct tls_session *session)
+key_method_2_write(struct buffer *buf, struct tls_multi *multi,
+ struct tls_session *session)
{
struct key_state *ks = &session->key[KS_PRIMARY]; /* primary key */
@@ -2386,12 +2387,17 @@ key_method_2_write(struct buffer *buf, struct tls_session *session)
goto error;
}
- /* Generate tunnel keys if we're a TLS server.
- * If we're a p2mp server and IV_NCP >= 2 is negotiated, the first key
- * generation is postponed until after the pull/push, so we can process pushed
- * cipher directives.
+ /*
+ * Generate tunnel keys if we're a TLS server.
+ *
+ * If we're a p2mp server to allow NCP, the first key
+ * generation is postponed until after the connect script finished and the
+ * NCP options can be processed. Since that always happens at after connect
+ * script options are available the CAS_SUCCEEDED status is identical to
+ * NCP options are processed and we have no extra state for NCP finished.
*/
- if (session->opt->server && !(session->opt->mode == MODE_SERVER && ks->key_id <= 0))
+ if (session->opt->server && (session->opt->mode != MODE_SERVER
+ || multi->multi_state == CAS_SUCCEEDED))
{
if (ks->authenticated > KS_AUTH_FALSE)
{
@@ -2847,7 +2853,7 @@ tls_process(struct tls_multi *multi,
if (!buf->len && ((ks->state == S_START && !session->opt->server)
|| (ks->state == S_GOT_KEY && session->opt->server)))
{
- if (!key_method_2_write(buf, session))
+ if (!key_method_2_write(buf, multi, session))
{
goto error;
}
|
