Re: [Openvpn-devel] Summary of the community meeting (26th March 2020)

[Selva Nair]

Hi,

Quoting from the 26th March meeting summary

> Noted that the combination of a username-only --auth-user-pass and
> --management-query-passwords does not work. Dazo will take a stab at
> fixing the actual problem. There is already a
> GET_USER_PASS_PASSWORD_ONLY flag which just needs to be processed
> correctly when the management interface is in action.

That's not very useful as GET_USER_PASS_PASSWORD_ONLY is currently
meant to prompt for the private key password, token password etc. The GUI will
treat any 'Auth' request to mean both username and password. In other
words, a management client only sees the prompt and there is no defined
prompt string for auth-user-pass password only.

Also, asking for a password without at least displaying the username is
confusing and there is currently no way of indicating the username in
such a request.

I considered several options for fixing this but all involve some
regression that may not be acceptable. An option is to step back when
only username is found in the file and ask for both username and password
from the management with the usual Auth request. Do this only if
--management-query-passwords is present.

But even that is a regression as currently, in such cases, the console
will be queried. There could be some users out there with those
options in the config, but not using the GUI or any management client,
and rely on prompting for password via the console.



> An attempt to document the limitation plus related discussion is here:
>
> 
>
> Further discussion of the issue is available here:
>
> 
>

Selva


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Summary of the community meeting (26th March 2020)

[Samuli Seppänen]

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Thu 26th March 2020
Time: 20:00 CET (19:00 UTC)

Planned meeting topics for this meeting were here:



Your local meeting time is easy to check from services such as



SUMMARY

cron2, dazo, lev and mattock participated in this meeting.

---

Discussed OpenVPN 2.5 status.

There is now a status section for MSI-related work:



All openvpn patches except for 11/12 have been merged which is very good
progress. Work on openvpn-build (MSI packaging) and tap-windows6 (MSM)
can really start once all of the openvpn work is in:




--

Noted that the "client-connect: split multi_connection_established into
separate functions" patch has a merge conflict in multi.c that somebody
needs to look at:



--

Noted that while --auth-token and --auth-gen-token are one of the nicest
new features in 2.5, they do not work right if combined with
--explicit-exit-notify on the server. This has to be fixed. Gory details
are available in the full chatlog.

--

Noted that the combination of a username-only --auth-user-pass and
--management-query-passwords does not work. Dazo will take a stab at
fixing the actual problem. There is already a
GET_USER_PASS_PASSWORD_ONLY flag which just needs to be processed
correctly when the management interface is in action.

An attempt to document the limitation plus related discussion is here:



Further discussion of the issue is available here:



--

Noted that removal of --disable-server needs review:



---

Full chatlog attached
(20:57:36) mattock: drum roll
(20:58:26) lev__: guten aben
(20:59:34) cron2: meow
(20:59:35) dazo: Hey!
(21:00:26) mattock: hi!
(21:01:52) dazo: mattock: can you put on your "checklist" after meetings to 
update /topic?  we always forget to update it 
(21:02:10) mattock: if somebody tells me how to do that
(21:02:14) mattock: I've never done it
(21:02:59) dazo: In (he)xchat it is just to modify the topic in the topic field 
and hit [enter]
(21:03:12) dazo: otherwise there is the /topic command
(21:03:34) mattock: ok, I'll check that out
(21:03:57) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2020-03-26
(21:04:17) mattock: https://patchwork.openvpn.net/patch/1045/ seems to be 
accepted already
(21:04:18) vpnHelper: Title: [Openvpn-devel,v3] travis-ci: add arm64, s390x 
builds. - Patchwork (at patchwork.openvpn.net)
(21:04:46) mattock: shall we move on to missing pieces in 2.5?
(21:05:21) dazo: Good idea
(21:05:43) mattock: I have the MSI/MSM status tracking in here now: 
https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25#MissingpiecesfromMSI
(21:05:50) cron2: I am mostly waiting to an 11/12 v2 from rozmansi, and a patch 
set from plaisthos...
(21:05:52) mattock: it seems that most of the openvpn patches are in
(21:05:58) mattock: not so earlier this week
(21:06:02) mattock: \o/
(21:06:05) cron2: lev has acked 01-10 + 12v2
(21:06:08) lev__: well, client connect isn't
(21:06:23) cron2: for MSM, most is in, for client-connect, waiting for the 
patch set
(21:06:48) mattock: once openvpn has all the pieces I think we can move to 
openvpn-build (MSI packaging) and tap-windows6 (MSM)
(21:08:52) mattock: the MSI PR in openvpn-build 
(https://github.com/OpenVPN/openvpn-build/pull/141) seems to have new commits 
to add the MSM stuff
(21:08:56) vpnHelper: Title: Windows MSI Packaging by rozmansi · Pull Request 
#141 · OpenVPN/openvpn-build · GitHub (at github.com)
(21:09:07) mattock: so I guess I just have to start experimenting with it once 
11/12 is in
(21:09:24) cron2: yes :)
(21:09:57) mattock: besides this MSI stuff: anything else in 2.5 that needs 
coordination?
(21:10:20) cron2: there's patches from plaisthos related to auth-gen-token
(21:10:27) cron2: which want a review :)
(21:11:31) dazo: It is still on my todo list ... I will try once again to dig 
it up once again ... I'm so sorry for these things falling through the cracks 
so often
(21:12:16) lev__: client-connect doesn't apply on latest master
(21:12:38) dazo: lev__: did you have a look on how complicated the conflict is?
(21:12:51) dazo: (using patch -p1 instead of git apply/am)
(21:13:15) lev__: no, I didn't
(21:13:24) lev__: something in multi.c
(21:18:02) dazo: lev__: do you have the patchwork link for it?  We should link 
to it on our status page
(21:18:56) cron2: 
https://patchwork.openvpn.net/project/openvpn2/list/?series=413
(21:18:57) vpnHelper: Title: OpenVPN 2 - Patchwork (at

Re: [Openvpn-devel] [PATCH 3/3] [auth-token] Document reneweal mechanic of auth-token in manual

[Nathan Stratton Treadway]

On Thu, Mar 26, 2020 at 18:23:32 +0100, Arne Schwabe wrote:
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index 864f94e8..f890e7a2 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -3741,6 +3741,12 @@ argument defines how long the generated token is 
> valid.  The
>  lifetime is defined in seconds.  If lifetime is not set
>  or it is set to 0, the token will never expire.
>  
> +The token will expire either after the lifetime of the token or after
> +not being renewed for 2 *
> +.B reneg\-sec
> +seconds. Clients are being send renewed tokens on every

s/send/sent/

(Would something like "Clients should normally be sent" or "During normal
operation, clients will be sent" be a clearer explanation of the topic?)

Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 2/3] [Auth-token] Fix session id in env missing first byte

[Arne Schwabe]

sizeof for a constant string return the size including the null byte.
For copying the session id this meant that we do not copy the first
byte. This made the session id reported to the external authenticator
one byte shorter than it was indented to be.
---
 src/openvpn/auth_token.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/auth_token.c b/src/openvpn/auth_token.c
index 6275299d..585679dc 100644
--- a/src/openvpn/auth_token.c
+++ b/src/openvpn/auth_token.c
@@ -121,7 +121,7 @@ add_session_token_env(struct tls_session *session, struct 
tls_multi *multi,
  */
 
 char session_id[AUTH_TOKEN_SESSION_ID_LEN*2] = {0};
-memcpy(session_id, session_id_source + sizeof(SESSION_ID_PREFIX),
+memcpy(session_id, session_id_source + strlen(SESSION_ID_PREFIX),
AUTH_TOKEN_SESSION_ID_LEN*8/6);
 
 setenv_str(session->opt->es, "session_id", session_id);
-- 
2.26.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 3/3] [auth-token] Document reneweal mechanic of auth-token in manual

[Arne Schwabe]

Our man page was missing the information that the life time of the
auth-token also depends on the reneg-sec
---
 doc/openvpn.8 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 864f94e8..f890e7a2 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -3741,6 +3741,12 @@ argument defines how long the generated token is valid.  
The
 lifetime is defined in seconds.  If lifetime is not set
 or it is set to 0, the token will never expire.
 
+The token will expire either after the lifetime of the token or after
+not being renewed for 2 *
+.B reneg\-sec
+seconds. Clients are being send renewed tokens on every
+TLS renogiation to keep the client's token updated.
+
 This feature is useful for environments which is configured
 to use One Time Passwords (OTP) as part of the user/password
 authentications and that authentication mechanism does not
-- 
2.26.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH 1/3] [Auth-token] Fix session id and initial timestamp not begin preserved

[Arne Schwabe]

In the initial state of checking whether an auth-token has been
validated, the check check if multi->auth_token is already set and
only then sets the value. This defeats the purpose and lead to always
a new auth-token with new session id and lifetime being generated when
the server restarts or the client reconnect to another server.
---
 src/openvpn/ssl_verify.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index da0966c5..226daf3d 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1381,7 +1381,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
  * to store the auth-token in multi->auth_token, so
  * the initial timestamp and session id can be extracted from it
  */
-if (multi->auth_token && (multi->auth_token_state_flags & 
AUTH_TOKEN_HMAC_OK)
+if ((multi->auth_token_state_flags & AUTH_TOKEN_HMAC_OK)
 && !(multi->auth_token_state_flags & AUTH_TOKEN_EXPIRED))
 {
 multi->auth_token = strdup(up->password);
-- 
2.26.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] PATCH V3 - changed remote lenght and refactored get_env

[Paolo Cerrito]

---
 .gitignore  | 1 +
 src/plugins/auth-pam/auth-pam.c | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0d68ec4b..3977882f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -72,3 +72,4 @@ nbproject
 test-driver
 compile
 stamp-h2
+outgoing/*
diff --git a/src/plugins/auth-pam/auth-pam.c b/src/plugins/auth-pam/auth-pam.c
index 9d8dfb95..b55a2ecd 100644
--- a/src/plugins/auth-pam/auth-pam.c
+++ b/src/plugins/auth-pam/auth-pam.c
@@ -115,7 +115,7 @@ struct user_pass {
 char password[128];
 char common_name[128];
 char response[128];
-char remote[128];
+char remote[51]; //51 as ipv6 form n:n:n:n:n:n:d.d.d.d/mask and 
terminator+1
 
 const struct name_value_list *name_value_list;
 };
@@ -518,7 +518,11 @@ openvpn_plugin_func_v1(openvpn_plugin_handle_t handle, 
const int type, const cha
 const char *username = get_env("username", envp);
 const char *password = get_env("password", envp);
 const char *common_name = get_env("common_name", envp) ? 
get_env("common_name", envp) : "";
-const char *remote = get_env("untrusted_ip", envp) ? 
get_env("untrusted_ip", envp) : get_env("untrusted_ip6", envp);
+const char *remote = get_env("untrusted_ip6", envp);
+   
+   if (remote == NULL){ 
+   remote = get_env("untrusted_ip", envp); //try to take ipv4 if 
not set ipv6
+   }
 
 if (username && strlen(username) > 0 && password)
 {
-- 
2.26.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] [PATCH V3] - changed remote lenght and refactored get_env

[Paolo Cerrito]

1) I put remote lenght to 51, as it have to hold ipv6/ipv4 ip address
plus string terminator.

2) As asked, i refactor the call to get_env, so now first of all there
   is a one call to get_env to get the ipv6 address, if is not set, and
   only in this case,  we recall get_env for ipv4.
---
 .gitignore  | 1 +
 src/plugins/auth-pam/auth-pam.c | 8 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 0d68ec4b..3977882f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -72,3 +72,4 @@ nbproject
 test-driver
 compile
 stamp-h2
+outgoing/*
diff --git a/src/plugins/auth-pam/auth-pam.c b/src/plugins/auth-pam/auth-pam.c
index 9d8dfb95..b55a2ecd 100644
--- a/src/plugins/auth-pam/auth-pam.c
+++ b/src/plugins/auth-pam/auth-pam.c
@@ -115,7 +115,7 @@ struct user_pass {
 char password[128];
 char common_name[128];
 char response[128];
-char remote[128];
+char remote[51]; //51 as ipv6 form n:n:n:n:n:n:d.d.d.d/mask and 
terminator+1
 
 const struct name_value_list *name_value_list;
 };
@@ -518,7 +518,11 @@ openvpn_plugin_func_v1(openvpn_plugin_handle_t handle, 
const int type, const cha
 const char *username = get_env("username", envp);
 const char *password = get_env("password", envp);
 const char *common_name = get_env("common_name", envp) ? 
get_env("common_name", envp) : "";
-const char *remote = get_env("untrusted_ip", envp) ? 
get_env("untrusted_ip", envp) : get_env("untrusted_ip6", envp);
+const char *remote = get_env("untrusted_ip6", envp);
+   
+   if (remote == NULL){ 
+   remote = get_env("untrusted_ip", envp); //try to take ipv4 if 
not set ipv6
+   }
 
 if (username && strlen(username) > 0 && password)
 {
-- 
2.26.0



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Possible memory alignment Problem in 2.4 ?

[Arne Schwabe]

Am 25.03.20 um 19:35 schrieb Michael Kress:
> Hello Arne,
> 
> Am Wed, 25 Mar 2020 12:50:34 +0100
> schrieb Arne Schwabe :
>>> 1) Do you run automated tests of the OpenVPN code on any build
>>> server? 
>>>
>>> 2) If that is the case, is there any test with a version, where 
>>>-DVERIFY_ALIGNMENT is enabled?
>>>
>>
>> I never heard of this option and Google does not want to spit
>> something out for me for that.
> 
> That's a #define in the OpenVPN code, for example in
> src/openvpn/buffer.h line 943 ;-)


Ah those. Yeah. They are mainly for performance reasons and debugging I
think. If I also remember correctly buffer.h is written in a way that
these *not* actually trigger unaligned access on a CPU level. But for
performance reason having the uint8_t array aligned to 4bytes will make
everything faster.

> RPI? You mean Raspberry PI?
> Maybe on this machine the problem is not a problem. We also use OpenVPN
> 2.4.7 on a ARMv7, and there is no obvious problem, just on the old
> ARMv4.
> 
> Finding all problematic places in the code will still be difficult.

I just look at my RPI and it seems that it has the option you mentioned
set by default:

cat /proc/cpu/alignment
User:   0
System: 0 (  (null))
Skipped:0
Half:   0
Word:   0
DWord:  0
Multi:  0
User faults:2 (fixup)

But it seems that the CPU will not trap but instead allows unaligned
memory access.

But since your machine requires that and setting it to 3 (warn+fixup)
actually fixes the problem you should get warning messages in your dmesg
output about the points in the code that trigger this problem.

And you could then either lookup with gdb what the IP addresse are
pointing to in the the code or (probably easier) configure the kernel to
send a SIGBUS, so you get a core image and can print a backtrace. If we
know what code path actually trigger the unaligned access we can take a
look and figure out what is wrong. Gert has done similar things with the
sparc machines in the past.

Arne



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel