date:20210520

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread tincantech via Openvpn-devel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

-‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 22:35, tincantech via Openvpn-devel 
 wrote:

> Hi,
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 20 May 2021 22:22, Jan Just Keijser janj...@nikhef.nl wrote:
>
> > On 20/05/21 23:12, tincantech wrote:
> >
> > > [...]
> > >
> > > > > So, why switch to .pem when it has never been used before by openvpn?
> > > > > If you are all happy to let it go that way then so-be-it,
> > > > > Hopefully this clarifies things:
> > > >
> > > > -   the default output format of OpenSSL is PEM-encoded ; openssl uses 
> > > > the
> > > > default extension .pem
> > > >
> > > > -   the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but
> > > > they've just been named differently by the easy-rsa tools to ensure 
> > > > that
> > > > the files can be easily loaded on Windows
> > > >
> > > > -   FTR: nearly all webservers I have ever seen are configured to use a
> > > > hostcert.pem and hostkey.pem and my guess is that there are (still)
> > > > more  Linux-based webservers out there than OpenVPN clients and 
> > > > servers.
> > > > Having said that, I do agree that after using .crt/.key files left 
> > > > and
> > > > right (to accomodate Windows users) for over 15 years, it does seem
> > > > confusing to start using files named .pem for peer-fingerprinting 
> > > > all
> > > > of  sudden. On the other hand, with peer-fingerprinting you don't
> > > > HAVE a .crt file (at least, you don't need one, technically) but 
> > > > only
> > > > a .key file. So choosing a different extension for 
> > > > peer-fingerprinting
> > > > does have its merits.
> > > >
>
> > > FTR: Openvpn still exchanges the full certificates in 
> > > peer-fingerprint mode.
> > >
>
> > meh ... I guess it was easier to implement it that way at the TLS level...
>
> I cannot comment on the code but there is the case of older clients which 
> require
> self-signed server".crt" (Easy-RSA) in place of the CA cert.
>
> > IMO that does add a "+1" to using .crt/.key  extensions - otherwise it
> > might confuse the heck out of end users (like overwriting the private
> > key with the public cert etc ... )
>
> That is another good point.
>
> > How do the examples distinguish between the cert and the private key in
> > this case then?
>
> Generally, the distinction between what is private and what is public
> has not been very well covered. Other than the notable exception of
> "Protect your Private CA key at all costs!"
>
> I have included this Private v Public information in the easy-pfp output.
> Seems like the only way to get things done sometimes is do-it-yourself ;-)
>
> Anyway, all other points aside, the point is that: Changing to .pem (not PEM)
> feels like an unnecessary complication.
>

I would like to hammer one final nail into this discussion.

Openvpn option names and inline tags ALL use ificate .crt and  .key.

They do not use .pem or PEM and none of the Official online documentation,
to date, references use of a {name}.pem file, other than far-flung cases.

The files generated in this tutorial will all be PEM encoded regardless.

This is why I asked the question of why Openvpn suddenly chooses to change
to a .pem extension and add this unnecessary complication.

Real users may see this as another hurdle which they just don't want to jump.
Do you want to drive them away .. ?

As I am also banned from #openvpn-meeting, so I leave this for you to discuss.

--
Richard
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJgpvNyACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ1U5wgAza4n5mxniWpvVrkSxRCN3TEc0MEafFb+Eza0uL/l9i5tVDDQ
A4ZwjBuRGgteJzNhbe3Q+YJzZZ1hjf9k9FjPwGtnUK49IZZt8OOe60bfiQt7
aSmhKMRyZzzjRgSv6QNdPWsZEB3JceZ572+EIi5zfQmz6V1q8USsPQPaUZoa
k65YA9Z+pU6xsm1+lKMLGbi8rzIvIhNYCEIZ4pGl5OzckQP7o7JKUanhOoHH
7KrD5Nu5ad4CtgMv72RYWCbmW5vsqIcOrYJIG7mASodCTGkL2JH5F2i8fVUJ
rg5OrvVViLewxTYyGCVc+PZ7ukB6l/bEYd8efA1G4carr6+hRDTfSA==
=T6wH
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread Jan Just Keijser


Hi,

On 20/05/21 21:49, tincantech via Openvpn-devel wrote:



Hi,
again, I do not understand why openvpn choose to switch to .pem
for this tutorial.  PEM -> Private Email, which this is not.
You have a certificate and a key and every other openvpn tutorial
on openvpn and probably the entire planet uses .crt and .key.
This seems to be a poor decision in my opinion.

pem as extension for keys is pretty common and specifies more the
encoding than the type. E.g. there is also the der encoding.

Arne

I accept the principle but openvpn *only* uses PEM-enc, that I know of.

So, why switch to .pem when it has never been used before by openvpn?

If you are all happy to let it go that way then so-be-it,



Hopefully this clarifies things:
- the default output format of OpenSSL is PEM-encoded ; openssl uses the 
default extension .pem
- the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but 
they've just been named differently by the easy-rsa tools to ensure that 
the files can be easily loaded on Windows


- FTR: nearly all webservers I have ever seen are configured to use a 
hostcert.pem and hostkey.pem and my guess is that there are (still) 
more  Linux-based webservers out there than OpenVPN clients and servers.


Having said that, I do agree that after using .crt/.key files left and 
right (to accomodate Windows users) for over 15 years, it does seem 
confusing to start using files named .pem for peer-fingerprinting all 
of  sudden. On the other hand, with peer-fingerprinting you don't  
*HAVE* a .crt file (at least, you don't need one, technically) but only 
a .key file. So choosing a different extension for peer-fingerprinting 
does have its merits.


HTH,

JJK



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

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread tincantech via Openvpn-devel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

‐‐‐ Original Message ‐‐‐
On Friday, 21 May 2021 00:40, tincantech  wrote:


> I would like to hammer one final nail into this discussion.
>
> Openvpn option names and inline tags ALL use ificate .crt and  
> .key.
>
> They do not use .pem or PEM and none of the Official online documentation,
> to date, references use of a {name}.pem file, other than far-flung cases.
>
> The files generated in this tutorial will all be PEM encoded regardless.

One final blow to the nail:

There is still the outstanding problem of --remote-cert-tls
which this tutorial does not discuss or solve.

The user log will show a WARNING message which they *cannot* solve
by means of your documentation.

--
Thanks
R

Unfairly banned.
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJgpvv5ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ2gkQf9FDId8dPnTrdC4+UHLhFOJOAYelk9SDQ1a3PSVhbag2ZO2FvM
3pCKfqdqSB0zYuu3rXBSdBoToovKw2Zc+8tnF8MaH6Oqm5+cmnRDfc03ZfDs
auqD04xIACnt3cPYAXXU+qXxGC8GpwLiUlEIEzlTcTsBrZyLMJhMPx146Dpe
MNRQtmYW+FqJfYHO7OscIb1uwUQ4WeWLY+76GkqhRMSPY6hrZ6CRU9htSdoU
w+B7KOGCKVE/FsyABNOz4IRNdnM3FMzvAvRD0UcOxJnmz/2BjImP6qNa7D0f
VGyg1kvnYQViVOOjE17ejvqbnLcRJRD53gRJcHpb/45UbVWNjSq04A==
=C3te
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread Selva Nair

Hi,

On Thu, May 20, 2021 at 3:50 PM tincantech via Openvpn-devel
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 20 May 2021 19:30, Arne Schwabe  wrote:
>
> > Am 20.05.2021 um 18:56 schrieb tincantech:
> >
> > > Hi,
> > > again, I do not understand why openvpn choose to switch to .pem
> > > for this tutorial.  PEM -> Private Email, which this is not.
> > > You have a certificate and a key and every other openvpn tutorial
> > > on openvpn and probably the entire planet uses .crt and .key.
> > > This seems to be a poor decision in my opinion.
> >
> > pem as extension for keys is pretty common and specifies more the
> > encoding than the type. E.g. there is also the der encoding.
> >
> > Arne
>
> I accept the principle but openvpn *only* uses PEM-enc, that I know of.
>
> So, why switch to .pem when it has never been used before by openvpn?
>
> If you are all happy to let it go that way then so-be-it,

I'm not sure I fully understand the discussion here, but we should
stick with consistent extensions for cert and key files in
documentation and examples. Currently we use the phrase "PEM certs" in
one place and "in .pem format" elsewhere. "PEM encoded" or "PEM
format" would be a better description. We use server.crt, server,key
etc in some places, .pem in some other.

OpenVPN doesn't care about the file extension of keys or certs as long
as the content is PEM. In that sense, having .pem in examples may
appear to be self-documenting but we have to be consistent. Use of
.pem has the drawback that we can use the same filename for cert and
key.

In practice I prefer .crt and .key as they are generally understood as
PEM encoded, and allow the same filename stub to be used for both cert
and key files: like server.crt and server.key while with pem it will
have to be something like server-cert.pem and server-key.pem.

Also, fwiw, .pem is not recognized by Windows explorer, .crt is -- one
could double click on the latter and load into the cert store, not so
with .pem.

Selva

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

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread Jan Just Keijser


On 20/05/21 23:12, tincantech wrote:

[...]

So, why switch to .pem when it has never been used before by openvpn?
If you are all happy to let it go that way then so-be-it,

Hopefully this clarifies things:

-   the default output format of OpenSSL is PEM-encoded ; openssl uses the
 default extension .pem

-   the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but
 they've just been named differently by the easy-rsa tools to ensure that
 the files can be easily loaded on Windows

-   FTR: nearly all webservers I have ever seen are configured to use a
 hostcert.pem and hostkey.pem and my guess is that there are (still)
 more  Linux-based webservers out there than OpenVPN clients and servers.

 Having said that, I do agree that after using .crt/.key files left and
 right (to accomodate Windows users) for over 15 years, it does seem
 confusing to start using files named .pem for peer-fingerprinting all
 of  sudden. On the other hand, with peer-fingerprinting you don't
 HAVE a .crt file (at least, you don't need one, technically) but only
 a .key file. So choosing a different extension for peer-fingerprinting
 does have its merits.

FTR: Openvpn still exchanges the full certificates in peer-fingerprint mode.


meh ... I guess it was easier to implement it that way at the TLS level...

IMO that does add a "+1" to using .crt/.key  extensions - otherwise it 
might confuse the heck out of end users (like overwriting the private 
key with the public cert etc ... )
How do the examples distinguish between the cert and the private key in 
this case then?


JJK


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

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread Arne Schwabe




Hopefully this clarifies things:
- the default output format of OpenSSL is PEM-encoded ; openssl uses 
the default extension .pem
- the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but 
they've just been named differently by the easy-rsa tools to ensure 
that the files can be easily loaded on Windows


- FTR: nearly all webservers I have ever seen are configured to use a 
hostcert.pem and hostkey.pem and my guess is that there are (still) 
more  Linux-based webservers out there than OpenVPN clients and servers.


Having said that, I do agree that after using .crt/.key files left and 
right (to accomodate Windows users) for over 15 years, it does seem 
confusing to start using files named .pem for peer-fingerprinting all 
of  sudden. On the other hand, with peer-fingerprinting you don't  
*HAVE* a .crt file (at least, you don't need one, technically) but 
only a .key file. So choosing a different extension for 
peer-fingerprinting does have its merits.


I am used a lot more used to calling these files pem files. I suggest we 
put that just on the agenda for the next openvpn-meeting, if people have 
strong preferences there.


And no, you still need cert and key like for a normal TLS connection 
with peer-fingerprint. It *only* replacing the normal check of the 
certificate with a fingerprint. Basically the same principle that 
browsers do when you do cert-pinning.


Arne



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

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread tincantech via Openvpn-devel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

‐‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 22:22, Jan Just Keijser  wrote:

> On 20/05/21 23:12, tincantech wrote:
>
> > [...]
> >
> > > > So, why switch to .pem when it has never been used before by openvpn?
> > > > If you are all happy to let it go that way then so-be-it,
> > > > Hopefully this clarifies things:
> > >
> > > -   the default output format of OpenSSL is PEM-encoded ; openssl uses the
> > > default extension .pem
> > >
> > > -   the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but
> > > they've just been named differently by the easy-rsa tools to ensure 
> > > that
> > > the files can be easily loaded on Windows
> > >
> > > -   FTR: nearly all webservers I have ever seen are configured to use a
> > > hostcert.pem and hostkey.pem and my guess is that there are (still)
> > > more  Linux-based webservers out there than OpenVPN clients and 
> > > servers.
> > > Having said that, I do agree that after using .crt/.key files left and
> > > right (to accomodate Windows users) for over 15 years, it does seem
> > > confusing to start using files named .pem for peer-fingerprinting all
> > > of  sudden. On the other hand, with peer-fingerprinting you don't
> > > HAVE a .crt file (at least, you don't need one, technically) but only
> > > a .key file. So choosing a different extension for peer-fingerprinting
> > > does have its merits.

> > FTR: Openvpn still exchanges the full certificates in peer-fingerprint 
> > mode.

> meh ... I guess it was easier to implement it that way at the TLS level...

I cannot comment on the code but there is the case of older clients which 
require
self-signed server".crt" (Easy-RSA) in place of the CA cert.

>
> IMO that does add a "+1" to using .crt/.key  extensions - otherwise it
> might confuse the heck out of end users (like overwriting the private
> key with the public cert etc ... )

That is another good point.


> How do the examples distinguish between the cert and the private key in
> this case then?

Generally, the distinction between what is private and what is public
has not been very well covered. Other than the notable exception of
"Protect your Private CA key at all costs!"

I have included this Private v Public information in the easy-pfp output.
Seems like the only way to get things done sometimes is do-it-yourself ;-)

Anyway, all other points aside, the point is that: Changing to .pem (not PEM)
feels like an unnecessary complication.

Thanks for all your input
R

-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJgptYeACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ0haQf/VyfMNC8x8r+8okE+aKW+kp+OMA58J6R7xOdv7D518BsBSJNX
BAqDiM1lalAwDvU7edKKMXhc0U2BOgMiaVOXp54jkZvXo7O5tt57A1O+tTKv
GNPzqDrhfGQRuaplHTMeiSkcWZOSmyNwIAW0vroCmiPBnGY2/F5GIL8T83Dp
qiNsST7Fug+u4nVUv/BUE2K81/B3pNz4Jy6hX2QMmq5LdRJgtNU37AAsZAQ5
Zwr4bewl/l8q36VjsX4QYNQgQekXdK8oT7LXZuqEy+tf4RnVHA8YDQZ2Ed5t
tfUUg/b02w3Ml6k9Wt3SHDgoXMAW0utUxxOWCMGVnEhuDRWg0kQ3rw==
=B+MM
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread tincantech via Openvpn-devel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256




Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 22:05, Jan Just Keijser  wrote:

> Hi,
>
> On 20/05/21 21:49, tincantech via Openvpn-devel wrote:
>
> > > > Hi,
> > > > again, I do not understand why openvpn choose to switch to .pem
> > > > for this tutorial.  PEM -> Private Email, which this is not.
> > > > You have a certificate and a key and every other openvpn tutorial
> > > > on openvpn and probably the entire planet uses .crt and .key.
> > > > This seems to be a poor decision in my opinion.
> > > > pem as extension for keys is pretty common and specifies more the
> > > > encoding than the type. E.g. there is also the der encoding.
> > >
> > > Arne
> > > I accept the principle but openvpn only uses PEM-enc, that I know of.
> >
> > So, why switch to .pem when it has never been used before by openvpn?
> > If you are all happy to let it go that way then so-be-it,
>
> Hopefully this clarifies things:
>
> -   the default output format of OpenSSL is PEM-encoded ; openssl uses the
> default extension .pem
>
> -   the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but
> they've just been named differently by the easy-rsa tools to ensure that
> the files can be easily loaded on Windows
>
> -   FTR: nearly all webservers I have ever seen are configured to use a
> hostcert.pem and hostkey.pem and my guess is that there are (still)
> more  Linux-based webservers out there than OpenVPN clients and servers.
>
> Having said that, I do agree that after using .crt/.key files left and
> right (to accomodate Windows users) for over 15 years, it does seem
> confusing to start using files named .pem for peer-fingerprinting all
> of  sudden. On the other hand, with peer-fingerprinting you don't 
> HAVE a .crt file (at least, you don't need one, technically) but only
> a .key file. So choosing a different extension for peer-fingerprinting
> does have its merits.

FTR: Openvpn still exchanges the full certificates in peer-fingerprint mode.


>
> HTH,
>
> JJK
>


-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJgptC5ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ2t0ggAxDZnJr8UhxV79fyAjnScANMeWbN3XZ/QqQuTsgaJp85Fibbz
weT1TfvihZ5l1rS6vh1nIDyTtoNRpqLHMxlaNWnmgN9tR4IRlQZuVR8svZl1
UYmrAm1H5g83yHef60nnIiOxGe8tnLdy/fmjqoRFsHaBwSM87zTQ8uG+UJnq
GIGhHbdLYWaH4C9SrJ+p64pZYdm3jaQpwZHdeg3rPdvHAgUixX13KWBU
J2UYseRDBLcvNfz6gAgQDtTJtdT9edH3h6m4Tyu0AsIw016hfREeNe20uzrX
uyQ6jGGovT2ki9alVN9P5v1k9uYVC0/1mYnFBLR8PI8effQd/zfLiA==
=KICZ
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] openvpnmsica: add ovpn-dco custom actions

2021-05-20 Thread Lev Stipakov

From: Lev Stipakov 

Add two custom actions to service ovpn-dco driver installation.

 - EvaluateDriver

Runs under user privileges. Determines what action (install/uninstall)
should be performed on ovpn-dco component.

 - ProcessDriver

Runs under SYSTEM privileges. Performs driver (un)installation.
During uninstall, all existing adapters with given hwid (ovpn-dco)
are removed.

The logic is inspired by custom actions from tap-windows6 installer
(https://github.com/OpenVPN/tap-windows6/tree/master/msm).

Signed-off-by: Lev Stipakov 
---
 src/openvpnmsica/Makefile.am|   2 +-
 src/openvpnmsica/openvpnmsica.c | 348 
 src/openvpnmsica/openvpnmsica.h |  30 +++
 3 files changed, 379 insertions(+), 1 deletion(-)

diff --git a/src/openvpnmsica/Makefile.am b/src/openvpnmsica/Makefile.am
index 9d18854a..a5d9c170 100644
--- a/src/openvpnmsica/Makefile.am
+++ b/src/openvpnmsica/Makefile.am
@@ -42,7 +42,7 @@ libopenvpnmsica_la_CFLAGS = \
-UNTDDI_VERSION -U_WIN32_WINNT \
-D_WIN32_WINNT=_WIN32_WINNT_VISTA \
-Wl,--kill-at
-libopenvpnmsica_la_LDFLAGS = -ladvapi32 -lole32 -lmsi -lsetupapi -liphlpapi 
-lshell32 -lshlwapi -lversion -no-undefined -avoid-version
+libopenvpnmsica_la_LDFLAGS = -ladvapi32 -lole32 -lmsi -lsetupapi -liphlpapi 
-lshell32 -lshlwapi -lversion -lnewdev -no-undefined -avoid-version
 endif
 
 libopenvpnmsica_la_SOURCES = \
diff --git a/src/openvpnmsica/openvpnmsica.c b/src/openvpnmsica/openvpnmsica.c
index 96652117..5e58b08e 100644
--- a/src/openvpnmsica/openvpnmsica.c
+++ b/src/openvpnmsica/openvpnmsica.c
@@ -43,6 +43,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 #ifdef _MSC_VER
 #pragma comment(lib, "advapi32.lib")
@@ -60,6 +64,12 @@
 #define MSICA_ADAPTER_TICK_SIZE (16*1024) /** Amount of tick space to reserve 
for one TAP/TUN adapter creation/deletition. */
 
 #define FILE_NEED_REBOOTL".ovpn_need_reboot"
+#define CMP_OVPN_DCO_INF_GUID   L"{4BE20469-2292-4AE2-B953-49AA0DA4165E}"
+#define ACTION_ADD_DRIVER   L"AddDriver"
+#define ACTION_DELETE_DRIVERL"DeleteDriver"
+#define ACTION_NOOP L"Noop"
+#define FILE_OVPN_DCO_INF   L"ovpn-dco.inf"
+#define OVPN_DCO_HWID   L"ovpn-dco"
 
 /**
  * Joins an argument sequence and sets it to the MSI property.
@@ -422,6 +432,11 @@ FindSystemInfo(_In_ MSIHANDLE hInstall)
 TEXT("Wintun") TEXT("\0"),
 TEXT("WINTUNADAPTERS"),
 TEXT("ACTIVEWINTUNADAPTERS"));
+find_adapters(
+hInstall,
+TEXT("ovpn-dco") TEXT("\0"),
+TEXT("OVPNDCOAPTERS"),
+TEXT("ACTIVEOVPNDCOADAPTERS"));
 
 if (bIsCoInitialized)
 {
@@ -1295,3 +1310,336 @@ CheckAndScheduleReboot(_In_ MSIHANDLE hInstall)
 }
 return ret;
 }
+
+static BOOL
+IsInstalling(_In_ INSTALLSTATE InstallState, _In_ INSTALLSTATE ActionState)
+{
+return INSTALLSTATE_LOCAL == ActionState || INSTALLSTATE_SOURCE == 
ActionState ||
+(INSTALLSTATE_DEFAULT == ActionState &&
+(INSTALLSTATE_LOCAL == InstallState || INSTALLSTATE_SOURCE == 
InstallState));
+}
+
+static BOOL
+IsReInstalling(_In_ INSTALLSTATE InstallState, _In_ INSTALLSTATE ActionState)
+{
+return (INSTALLSTATE_LOCAL == ActionState || INSTALLSTATE_SOURCE == 
ActionState ||
+INSTALLSTATE_DEFAULT == ActionState) &&
+(INSTALLSTATE_LOCAL == InstallState || INSTALLSTATE_SOURCE == 
InstallState);
+}
+
+static BOOL
+IsUninstalling(_In_ INSTALLSTATE InstallState, _In_ INSTALLSTATE ActionState)
+{
+return (INSTALLSTATE_ABSENT == ActionState || INSTALLSTATE_REMOVED == 
ActionState) &&
+(INSTALLSTATE_LOCAL == InstallState || INSTALLSTATE_SOURCE == 
InstallState);
+}
+
+static UINT
+GetComponentNameById(_In_ MSIHANDLE hInstall, _In_ LPCTSTR componentId, _Out_ 
LPTSTR name, DWORD len)
+{
+UINT ret = 0;
+MSIHANDLE record = 0;
+MSIHANDLE view = 0;
+
+name[len - 1] = '\0';
+
+/* Open MSI database. */
+MSIHANDLE db = MsiGetActiveDatabase(hInstall);
+if (db == 0)
+{
+msg(M_NONFATAL, "%s: MsiGetActiveDatabase failed", __FUNCTION__);
+ret = ERROR_INVALID_HANDLE;
+goto cleanup;
+}
+
+TCHAR cmd[0x400];
+_stprintf_s(cmd, _countof(cmd), L"SELECT `Component` FROM `Component` 
WHERE `ComponentId` = '%s'", componentId);
+
+ret = MsiDatabaseOpenView(db, cmd, );
+if (ret != ERROR_SUCCESS)
+{
+goto cleanup;
+}
+
+ret = MsiViewExecute(view, 0);
+if (ret != ERROR_SUCCESS)
+{
+goto cleanup;
+}
+
+ret = MsiViewFetch(view, );
+if (ret != ERROR_SUCCESS)
+{
+goto cleanup;
+}
+
+ret = MsiRecordGetString(record, 1, name, );
+if (ret != ERROR_SUCCESS)
+{
+goto cleanup;
+}
+
+cleanup:
+MsiCloseHandle(view);
+MsiCloseHandle(record);
+MsiCloseHandle(db);
+
+return ret;
+}
+
+UINT __stdcall
+EvaluateDriver(_In_ MSIHANDLE hInstall)
+{
+#ifdef _MSC_VER
+#pragma comment(linker,

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread Gert Doering

Hi,

On Thu, May 20, 2021 at 04:56:16PM +, tincantech via Openvpn-devel wrote:
> again, I do not understand why openvpn choose to switch to .pem
> for this tutorial.  PEM -> Private Email, which this is not.

https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


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

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread tincantech via Openvpn-devel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

again, I do not understand why openvpn choose to switch to .pem
for this tutorial.  PEM -> Private Email, which this is not.
You have a certificate and a key and every other openvpn tutorial
on openvpn and probably the entire planet uses .crt and .key.
This seems to be a poor decision in my opinion.

And I presume that --tun-mtu 1400 is not going to break --mssfix 1450

There is also another advantage of using this method which is not
documented.  Each client can build its own cert/key and send the
finger-print to the server in clear text, as can the server FP
be sent to the clients.

And apologies for the plug but easy-pfp can do all this and more
even easier. https://github.com/TinCanTech/easy-pfp


Sent with ProtonMail Secure Email.  Which does not know how to
reply to a git formatted patch and has other stupid quirks too.
sed formatted reply.


‐‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 16:09, Arne Schwabe  wrote:

> This is meant to give new users a quickstart for a useable OpenVPN
> setup. Our own documentation is lacking in this regard and many
> tutorials that can be found online are often questionable in some
> aspects.
>
> Linking the individaul RST file on github also give a tutorial
> in a nicely formatted way.

individaul -> individual (ua)


>
> Patch V2: Fix grammar/spelling mistakes (thanks ticantech), move
>   to openvpn-examples(5).
>
> Signed-off-by: Arne Schwabe 
> ---
>  Changes.rst  |   4 +
>  doc/Makefile.am  |   1 +
>  doc/man-sections/example-fingerprint.rst | 196 +++
>  doc/openvpn-examples.5.rst   |   1 +
>  4 files changed, 202 insertions(+)
>  create mode 100644 doc/man-sections/example-fingerprint.rst
>
> diff --git a/Changes.rst b/Changes.rst
> index 9185b55f7..5ac24307f 100644
> --- a/Changes.rst
> +++ b/Changes.rst
> @@ -25,6 +25,10 @@ Certificate pinning/verify peer fingerprint
>  fingerprint of the peer. The option takes use a number of allowed
>  SHA256 certificate fingerprints.
>
> +See the man page section "Small OpenVPN setup with peer-fingerprint"
> +for a tutorial on how to use this feature. This is also available online
> +under 
> https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst
> +
>  TLS mode with self-signed certificates
>  When ``--peer-fingerprint`` is used, the ``--ca`` and ``--capath`` option
>  become optional. This allows for small OpenVPN setups without setting up
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index 1dbbddf58..d86560174 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -25,6 +25,7 @@ dist_noinst_DATA = \
>   man-sections/client-options.rst \
>   man-sections/connection-profiles.rst \
>   man-sections/encryption-options.rst \
> + man-sections/example-fingerprint.rst \
>   man-sections/examples.rst \
>   man-sections/generic-options.rst \
>   man-sections/inline-files.rst \
> diff --git a/doc/man-sections/example-fingerprint.rst 
> b/doc/man-sections/example-fingerprint.rst
> new file mode 100644
> index 0..c91ca64b9
> --- /dev/null
> +++ b/doc/man-sections/example-fingerprint.rst
> @@ -0,0 +1,196 @@
> +Small OpenVPN setup with peer-fingerprint
> +=
> +This section consists of instructions how to build a small OpenVPN setup 
> with the
> +:code:`peer-fingerprint` option. This has the advantage of being easy to 
> setup
> +and should be suitable for most small lab and home setups without the need 
> for a PKI.
> +For bigger scale setup setting up a PKI (e.g. via easy-rsa) is still 
> recommended.
> +
> +Both server and client configuration can of be further modified to customise 
> the
> +setup.
> +
> +Server setup
> +
> +1. Install openvpn
> +
> +   Compile from source-code (see `INSTALL` file) or install via a 
> distribution (apt/yum/ports)
> +   or via installer (Windows).
> +
> +2. Generate a self-signed certificate for the server:
> +   ::
> +
> +openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout 
> serverkey.pem -out server.pem -nodes -sha256 -days 3650 -subj '/CN=server'
> +
> +3. Generate SHA256 fingerprint of the server certificate
> +
> +   Use the OpenSSL command line utility to view the fingerprint of just
> +   created certificate:
> +   ::
> +
> +openssl x509 -fingerprint -sha256 -in server.pem -noout
> +
> +   This output something similar to:
> +   ::
> +
> + SHA256 
> Fingerprint=00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
> +
> +
> +3. Write a server configuration (`server.conf`):
> +::
> +
> +# The server certificate we created in step 1
> +cert server.pem
> +key serverkey.pem
> +
> +dh none
> +dev tun
> +
> +# Listen on IPv6+IPv4 simultaneously
> +proto udp6
> +
> +# The ip

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread tincantech via Openvpn-devel

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

‐‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 19:30, Arne Schwabe  wrote:

> Am 20.05.2021 um 18:56 schrieb tincantech:
>
> > Hi,
> > again, I do not understand why openvpn choose to switch to .pem
> > for this tutorial.  PEM -> Private Email, which this is not.
> > You have a certificate and a key and every other openvpn tutorial
> > on openvpn and probably the entire planet uses .crt and .key.
> > This seems to be a poor decision in my opinion.
>
> pem as extension for keys is pretty common and specifies more the
> encoding than the type. E.g. there is also the der encoding.
>
> Arne

I accept the principle but openvpn *only* uses PEM-enc, that I know of.

So, why switch to .pem when it has never been used before by openvpn?

If you are all happy to let it go that way then so-be-it,

Thanks
R

-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJgpr0yACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ3AXgf9H+mL+H1aPZ/Gk0lTukZEP7FVXHkO2LBf49KA/YmoyhbHYAFf
sICvASsTlkA0q3wuKYzXs8bspMGiebOeqcoJi7QvJSaAq4sDLvWopz/VmN96
SmB33OnN/jYHQmKpk2qOMeZv6PyhFyjFb/3j1ymQ2zuYXh8osrSiiRHftwSx
hXg8CMyXOA0THrK6H9mnxisLuss7uhVsclwTOSKMOnRj0NiEx5tFg1itn7+u
YmRL/h2taDC6skHbF5PPfU1x/M6HtG05ZajAtNfh3bc0Zw4S7bRiEUc4+4qb
f8GEEufo2WAg4CUwaCVJ9O5pSewk48OAScHGx9RMybvfZ1X6V5xnqA==
=EBa6
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread Arne Schwabe



Am 20.05.2021 um 18:56 schrieb tincantech:

Hi,

again, I do not understand why openvpn choose to switch to .pem
for this tutorial.  PEM -> Private Email, which this is not.
You have a certificate and a key and every other openvpn tutorial
on openvpn and probably the entire planet uses .crt and .key.
This seems to be a poor decision in my opinion.


pem as extension for keys is pretty common and specifies more the 
encoding than the type. E.g. there is also the der encoding.


Arne



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

[Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

2021-05-20 Thread Arne Schwabe

This is meant to give new users a quickstart for a useable OpenVPN
setup. Our own documentation is lacking in this regard and many
tutorials that can be found online are often questionable in some
aspects.

Linking the individaul RST file on github also give a tutorial
in a nicely formatted way.

Patch V2: Fix grammar/spelling mistakes (thanks ticantech), move
  to openvpn-examples(5).

Signed-off-by: Arne Schwabe 
---
 Changes.rst  |   4 +
 doc/Makefile.am  |   1 +
 doc/man-sections/example-fingerprint.rst | 196 +++
 doc/openvpn-examples.5.rst   |   1 +
 4 files changed, 202 insertions(+)
 create mode 100644 doc/man-sections/example-fingerprint.rst

diff --git a/Changes.rst b/Changes.rst
index 9185b55f7..5ac24307f 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -25,6 +25,10 @@ Certificate pinning/verify peer fingerprint
 fingerprint of the peer. The option takes use a number of allowed
 SHA256 certificate fingerprints.
 
+See the man page section "Small OpenVPN setup with peer-fingerprint"
+for a tutorial on how to use this feature. This is also available online
+under 
https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst
+
 TLS mode with self-signed certificates
 When ``--peer-fingerprint`` is used, the ``--ca`` and ``--capath`` option
 become optional. This allows for small OpenVPN setups without setting up
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 1dbbddf58..d86560174 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -25,6 +25,7 @@ dist_noinst_DATA = \
man-sections/client-options.rst \
man-sections/connection-profiles.rst \
man-sections/encryption-options.rst \
+   man-sections/example-fingerprint.rst \
man-sections/examples.rst \
man-sections/generic-options.rst \
man-sections/inline-files.rst \
diff --git a/doc/man-sections/example-fingerprint.rst 
b/doc/man-sections/example-fingerprint.rst
new file mode 100644
index 0..c91ca64b9
--- /dev/null
+++ b/doc/man-sections/example-fingerprint.rst
@@ -0,0 +1,196 @@
+Small OpenVPN setup with peer-fingerprint
+=
+This section consists of instructions how to build a small OpenVPN setup with 
the
+:code:`peer-fingerprint` option. This has the advantage of being easy to setup
+and should be suitable for most small lab and home setups without the need for 
a PKI.
+For bigger scale setup setting up a PKI (e.g. via easy-rsa) is still 
recommended.
+
+Both server and client configuration can of be further modified to customise 
the
+setup.
+
+Server setup
+
+1. Install openvpn
+
+   Compile from source-code (see `INSTALL` file) or install via a distribution 
(apt/yum/ports)
+   or via installer (Windows).
+
+2. Generate a self-signed certificate for the server:
+   ::
+
+openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout 
serverkey.pem -out server.pem -nodes -sha256 -days 3650 -subj '/CN=server'
+
+3. Generate SHA256 fingerprint of the server certificate
+
+   Use the OpenSSL command line utility to view the fingerprint of just
+   created certificate:
+   ::
+
+openssl x509 -fingerprint -sha256 -in server.pem -noout
+
+   This output something similar to:
+   ::
+
+ SHA256 
Fingerprint=00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
+
+
+3. Write a server configuration (`server.conf`):
+::
+
+# The server certificate we created in step 1
+cert server.pem
+key serverkey.pem
+
+dh none
+dev tun
+
+# Listen on IPv6+IPv4 simultaneously
+proto udp6
+
+# The ip address the server will distribute
+server 192.168.234.0 255.255.255.0
+server-ipv6 fd00:6f76:706e::/64
+
+# A tun-mtu of 1400 avoids problems of too big packets after VPN 
encapsulation
+tun-mtu 1400
+
+# The fingerprints of your clients. After adding/removing one here restart 
the
+# server
+
+
+
+# Notify clients when you restart the server to reconnect quickly
+explicit-exit-notify 1
+
+# Ping every 60s, restart if no data received for 5 minutes
+keepalive 60 300
+
+4. Add at least one client as described in the client section.
+
+5. Start the server.
+- On systemd based distributions move `server.pem`, `serverkey.pem` and
+  `server.conf` to :code:`/etc/openvpn/server` and start it via systemctl
+
+  ::
+
+  sudo mv server.conf serverkey.pem server.pem /etc/openvpn/server
+
+  sudo systemctl start openvpn-server@server
+
+Adding a client
+---
+1. Install OpenVPN
+
+2. Generate a self-signed certificate for the client. In this example the 
client
+   name is alice. Each client should have a unique name. Replace alice with a
+   different name for each client.
+   ::
+
+  openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1)

[Openvpn-devel] [PATCH v2 1/2] Move examples into openvpn-examples(5) man page

2021-05-20 Thread Arne Schwabe

Signed-off-by: Arne Schwabe 
---
 .gitignore |  2 ++
 doc/Makefile.am| 25 +
 doc/openvpn-examples.5.rst | 17 +
 doc/openvpn.8.rst  |  2 +-
 4 files changed, 41 insertions(+), 5 deletions(-)
 create mode 100644 doc/openvpn-examples.5.rst

diff --git a/.gitignore b/.gitignore
index 25d06235b..178076ede 100644
--- a/.gitignore
+++ b/.gitignore
@@ -49,6 +49,8 @@ version.sh
 msvc-env-local.bat
 config-msvc-local.h
 config-msvc-version.h
+doc/openvpn-examples.5
+doc/openvpn-examples.5.html
 doc/openvpn.8
 doc/openvpn.8.html
 /doc/doxygen/html/
diff --git a/doc/Makefile.am b/doc/Makefile.am
index e411f5f9d..1dbbddf58 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -20,6 +20,7 @@ dist_doc_DATA = \
 dist_noinst_DATA = \
README.plugins interactive-service-notes.rst \
openvpn.8.rst \
+openvpn-examples.5.rst \
man-sections/advanced-options.rst \
man-sections/client-options.rst \
man-sections/connection-profiles.rst \
@@ -52,6 +53,14 @@ else
@echo "Missing python-docutils - skipping man page generation"
 endif
 
+openvpn-examples.5 :
+if HAVE_PYDOCUTILS
+   $(RST2MAN) $(srcdir)/$@.rst > $@
+else
+   @echo "Missing python-docutils - skipping man page generation"
+endif
+
+
 openvpn.8.html:
 if HAVE_PYDOCUTILS
$(RST2HTML) $(srcdir)/openvpn.8.rst > $@
@@ -59,13 +68,21 @@ else
@echo "Missing python-docutils - skipping man/html page generation"
 endif
 
+openvpn-examples.5.html:
+if HAVE_PYDOCUTILS
+   $(RST2HTML) $(srcdir)/openvpn-examples.5.rst > $@
+else
+   @echo "Missing python-docutils - skipping man/html page generation"
+endif
+
+
 if HAVE_PYDOCUTILS
-dist_noinst_DATA += openvpn.8
-dist_html_DATA = openvpn.8.html
+dist_noinst_DATA += openvpn.8 openvpn-examples.5
+dist_html_DATA = openvpn.8.html openvpn-examples.5.html
 
 # Failsafe - do not delete these files unless we can recreate them
 CLEANFILES = \
-openvpn.8 openvpn.8.html
+openvpn.8 openvpn.8.html openvpn-examples.5 openvpn-examples.5.html
 
 endif
 
@@ -74,4 +91,4 @@ else
 dist_man_MANS = openvpn.8
 endif
 
-dist-hook : openvpn.8 openvpn.8.html
+dist-hook : openvpn.8 openvpn.8.html openvpn-examples.5 openvpn-examples.5.html
diff --git a/doc/openvpn-examples.5.rst b/doc/openvpn-examples.5.rst
new file mode 100644
index 0..988b6027b
--- /dev/null
+++ b/doc/openvpn-examples.5.rst
@@ -0,0 +1,17 @@
+===
+ openvpn examples
+===
+-
+ Secure IP tunnel daemon
+-
+
+:Manual section: 5
+:Manual group: Configuration files
+
+
+INTRODUCTION
+
+
+This man page gives a few simple examples to create OpenVPN setups and 
configuration files.
+
+.. include:: man-sections/examples.rst
diff --git a/doc/openvpn.8.rst b/doc/openvpn.8.rst
index db81274fa..995467478 100644
--- a/doc/openvpn.8.rst
+++ b/doc/openvpn.8.rst
@@ -86,7 +86,6 @@ placed in a configuration file.
 .. include:: man-sections/connection-profiles.rst
 .. include:: man-sections/inline-files.rst
 .. include:: man-sections/signals.rst
-.. include:: man-sections/examples.rst
 
 
 FAQ
@@ -134,6 +133,7 @@ Report all bugs to the OpenVPN team i...@openvpn.net
 SEE ALSO
 
 
+``openvpn-examples``\(5),
 ``dhcpcd``\(8),
 ``ifconfig``\(8),
 ``openssl``\(1),
-- 
2.31.1



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

[Openvpn-devel] [PATCH v2 1/9] Move auth_token_state from multi to key_state

2021-05-20 Thread Arne Schwabe

The auth-token check is tied to the username/password that is coming
via a specific SSL session, so keep the state also in the key_state
structure.

This also ensures the auth_token_state is always set to 0 on a new
session since we clear the key_state object at the start of a new
SSL session.

This is a prerequisite patch to fix 2020-15078 in the following two
commits.

This also applies the changes to the auth_token_test.c. The change of
tls_session to a pointer is necessary since before that we had tls_session
not tied to the multi and had two tls_session used in the test. One
implicitly in tls_multi and one explicit one. Merge these to one.

Signed-off-by: Arne Schwabe 
---
 src/openvpn/auth_token.c   | 12 +--
 src/openvpn/ssl_common.h   |  4 +-
 src/openvpn/ssl_verify.c   |  8 +-
 tests/unit_tests/openvpn/test_auth_token.c | 91 +++---
 4 files changed, 60 insertions(+), 55 deletions(-)

diff --git a/src/openvpn/auth_token.c b/src/openvpn/auth_token.c
index d571b686e..0ea6d1832 100644
--- a/src/openvpn/auth_token.c
+++ b/src/openvpn/auth_token.c
@@ -57,6 +57,7 @@ add_session_token_env(struct tls_session *session, struct 
tls_multi *multi,
 return;
 }
 
+int auth_token_state_flags = 
session->key[KS_PRIMARY].auth_token_state_flags;
 
 const char *state;
 
@@ -64,9 +65,9 @@ add_session_token_env(struct tls_session *session, struct 
tls_multi *multi,
 {
 state = "Initial";
 }
-else if (multi->auth_token_state_flags & AUTH_TOKEN_HMAC_OK)
+else if (auth_token_state_flags & AUTH_TOKEN_HMAC_OK)
 {
-switch (multi->auth_token_state_flags & 
(AUTH_TOKEN_VALID_EMPTYUSER|AUTH_TOKEN_EXPIRED))
+switch (auth_token_state_flags & 
(AUTH_TOKEN_VALID_EMPTYUSER|AUTH_TOKEN_EXPIRED))
 {
 case 0:
 state = "Authenticated";
@@ -98,8 +99,8 @@ add_session_token_env(struct tls_session *session, struct 
tls_multi *multi,
 
 /* We had a valid session id before */
 const char *session_id_source;
-if (multi->auth_token_state_flags & AUTH_TOKEN_HMAC_OK
-&& !(multi->auth_token_state_flags & AUTH_TOKEN_EXPIRED))
+if (auth_token_state_flags & AUTH_TOKEN_HMAC_OK
+&& !(auth_token_state_flags & AUTH_TOKEN_EXPIRED))
 {
 session_id_source = up->password;
 }
@@ -236,7 +237,8 @@ generate_auth_token(const struct user_pass *up, struct 
tls_multi *multi)
  * a new token with the empty username since we do not want to loose
  * the information that the username cannot be trusted
  */
-if (multi->auth_token_state_flags & AUTH_TOKEN_VALID_EMPTYUSER)
+struct key_state *ks = >session[TM_ACTIVE].key[KS_PRIMARY];
+if (ks->auth_token_state_flags & AUTH_TOKEN_VALID_EMPTYUSER)
 {
 hmac_ctx_update(ctx, (const uint8_t *) "", 0);
 }
diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
index 61cae7419..53325e556 100644
--- a/src/openvpn/ssl_common.h
+++ b/src/openvpn/ssl_common.h
@@ -182,6 +182,8 @@ enum auth_deferred_result {
 struct key_state
 {
 int state;
+/** The state of the auth-token sent from the client */
+int auth_token_state_flags;
 
 /**
  * Key id for this key_state,  inherited from struct tls_session.
@@ -598,8 +600,6 @@ struct tls_multi
  * OpenVPN 3 clients sometimes wipes or replaces the username with a
  * username hint from their config.
  */
-int auth_token_state_flags;
-/**< The state of the auth-token sent from the client last time */
 
 /* For P_DATA_V2 */
 uint32_t peer_id;
diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index 0b41eea2d..7992a6eb9 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1484,7 +1484,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
  */
 if (session->opt->auth_token_generate && is_auth_token(up->password))
 {
-multi->auth_token_state_flags = verify_auth_token(up, multi, session);
+ks->auth_token_state_flags = verify_auth_token(up, multi, session);
 if (session->opt->auth_token_call_auth)
 {
 /*
@@ -1493,7 +1493,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
  * decide what to do with the result
  */
 }
-else if (multi->auth_token_state_flags == AUTH_TOKEN_HMAC_OK)
+else if (ks->auth_token_state_flags == AUTH_TOKEN_HMAC_OK)
 {
 /*
  * We do not want the EXPIRED or EMPTY USER flags here so check
@@ -1592,8 +1592,8 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
  * the initial timestamp and session id can be extracted from it
  */
 if (!multi->auth_token
-&& (multi->auth_token_state_flags & AUTH_TOKEN_HMAC_OK)
-&& !(multi->auth_token_state_flags & AUTH_TOKEN_EXPIRED))
+&&

[Openvpn-devel] [PATCH v2 9/9] Support NCP in pure P2P VPN setups

2021-05-20 Thread Arne Schwabe

Currently P2P mode of OpenVPN is on of the few places that cannot negotiate
modern OpenVPN features. This becomes more and more problematic since P2P and
P2MP code diverge more and more and also the lack of switching to more
advanced features like Data v2 currently blocks P2P mode from working
together with the upcoming ovpn-dco support.

This NCP support is a lot simpler and works in the following way:

- P2P peer announce an extremely limited IV_ variable set
  (IV_PROTO and IV_CIPHERS)
- Both peers check if the IV_PROTO_NCP_P2P bit is present in IV_PROTO
- if yes both sides deterministically determine according to
  IV_PROTO and IV_CIPHER what options can be used and start using these

There are no poor man's NCP or other compatibility workaround like in the
normal NCP, making this NCP leaner and more deterministic.

Signed-off-by: Arne Schwabe 
---
 src/openvpn/init.c  | 100 ---
 src/openvpn/options.c   |   8 +-
 src/openvpn/ssl.c   | 120 +++
 src/openvpn/ssl.h   |   5 +
 src/openvpn/ssl_backend.h   |   1 +
 src/openvpn/ssl_common.h|  10 ++
 src/openvpn/ssl_ncp.c   | 145 
 src/openvpn/ssl_ncp.h   |  25 +
 tests/unit_tests/openvpn/test_ncp.c |  11 +++
 9 files changed, 366 insertions(+), 59 deletions(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 38abf9f3a..5d4852ae1 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -68,6 +68,7 @@ static const char *saved_pid_file_name; /* GLOBAL */
 #define CF_INIT_TLS_AUTH_STANDALONE (1<<2)
 
 static void do_init_first_time(struct context *c);
+static bool do_deferred_p2p_ncp(struct context *c);
 
 void
 context_clear(struct context *c)
@@ -2151,6 +2152,14 @@ do_up(struct context *c, bool pulled_options, unsigned 
int option_types_found)
 return false;
 }
 }
+else if (c->mode == MODE_POINT_TO_POINT)
+{
+if (!do_deferred_p2p_ncp(c))
+{
+msg(D_TLS_ERRORS, "ERROR: Failed to apply P2P negotiated 
protocol options");
+return false;
+}
+}
 
 /* if --up-delay specified, open tun, do ifconfig, and run up script 
now */
 if (c->options.up_delay || PULL_DEFINED(>options))
@@ -2238,6 +2247,72 @@ pull_permission_mask(const struct context *c)
 return flags;
 }
 
+static
+void adjust_mtu_peerid(struct context *c)
+{
+frame_add_to_extra_frame(>c2.frame, +3); /* peer-id overhead */
+if (!c->options.ce.link_mtu_defined)
+{
+frame_add_to_link_mtu(>c2.frame, +3);
+msg(D_PUSH, "OPTIONS IMPORT: adjusting link_mtu to %d",
+EXPANDED_SIZE(>c2.frame));
+}
+else
+{
+msg(M_WARN, "OPTIONS IMPORT: WARNING: peer-id set, but link-mtu"
+" fixed by config - reducing tun-mtu to %d, expect"
+" MTU problems", TUN_MTU_SIZE(>c2.frame) );
+}
+}
+
+static bool
+do_deferred_p2p_ncp(struct context *c)
+{
+
+if (!c->c2.tls_multi)
+{
+return true;
+}
+
+if (c->c2.tls_multi->use_peer_id)
+{
+adjust_mtu_peerid(c);
+}
+
+struct tls_session *session = >c2.tls_multi->session[TM_ACTIVE];
+
+const char *ncp_cipher = get_p2p_ncp_cipher(session, 
c->c2.tls_multi->peer_info,
+>options.gc);
+
+if (ncp_cipher)
+{
+c->options.ciphername = ncp_cipher;
+}
+else if (!c->options.enable_ncp_fallback)
+{
+msg(D_TLS_ERRORS, "ERROR: failed to negotiate cipher with peer and "
+  "--data-ciphers-fallback not enabled. No useable "
+  "data channel cipher");
+return false;
+}
+
+struct frame *frame_fragment = NULL;
+#ifdef ENABLE_FRAGMENT
+if (c->options.ce.fragment)
+{
+frame_fragment = >c2.frame_fragment;
+}
+#endif
+
+if (!tls_session_update_crypto_params(session, >options, >c2.frame,
+ frame_fragment))
+{
+msg(D_TLS_ERRORS, "ERROR: failed to set crypto cipher");
+return false;
+}
+return true;
+}
+
 /*
  * Handle non-tun-related pulled options.
  */
@@ -2325,19 +2400,7 @@ do_deferred_options(struct context *c, const unsigned 
int found)
 msg(D_PUSH, "OPTIONS IMPORT: peer-id set");
 c->c2.tls_multi->use_peer_id = true;
 c->c2.tls_multi->peer_id = c->options.peer_id;
-frame_add_to_extra_frame(>c2.frame, +3); /* peer-id overhead */
-if (!c->options.ce.link_mtu_defined)
-{
-frame_add_to_link_mtu(>c2.frame, +3);
-msg(D_PUSH, "OPTIONS IMPORT: adjusting link_mtu to %d",
-EXPANDED_SIZE(>c2.frame));
-}
-else
-{
-msg(M_WARN, "OPTIONS IMPORT: WARNING: peer-id set, but link-mtu"
-

[Openvpn-devel] [PATCH v2 2/9] Implement auth-token-user

2021-05-20 Thread Arne Schwabe

When not using username and password (i.e. auth-user-pass) it can still make
to provide the client with an auth-token, e.g. for allowing a session to
continue after a reconnect without requiring 2FA again.

However, without --auth-user-pass openvpn does not have a username and will
ignore any pushed auth-token command.

This patch adds support for auth-token-user to set the username that should
be used for auth-token

The spec of using auth-token-user base64-encoded-user are the ones that
OpenVPN3 already implements.

Patch V2: Improve style, fix comments and commit message

Signed-off-by: Arne Schwabe 
---
 doc/man-sections/client-options.rst |  8 +++
 src/openvpn/misc.c  | 37 +
 src/openvpn/misc.h  | 21 +---
 src/openvpn/options.c   |  5 
 src/openvpn/ssl.c   | 12 +++---
 src/openvpn/ssl.h   |  2 ++
 6 files changed, 74 insertions(+), 11 deletions(-)

diff --git a/doc/man-sections/client-options.rst 
b/doc/man-sections/client-options.rst
index af21fbcd7..c5b7ad960 100644
--- a/doc/man-sections/client-options.rst
+++ b/doc/man-sections/client-options.rst
@@ -50,6 +50,14 @@ configuration.
   after a failed auth. Older clients will keep using the token value and
   react according to ``--auth-retry``
 
+--auth-token-user base64username
+  Companion option to ``--auth-token``. This options allows to override
+  the username used by the client when reauthenticating with the 
``auth-token``.
+  It also allows to use ``--auth-token`` in setups that normally do not use
+  username and password.
+
+  The username has to be base64 encoded.
+
 --auth-user-pass
   Authenticate with server using username/password.
 
diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
index 650daa0c6..29061cd6f 100644
--- a/src/openvpn/misc.c
+++ b/src/openvpn/misc.c
@@ -490,22 +490,49 @@ void
 set_auth_token(struct user_pass *up, struct user_pass *tk, const char *token)
 {
 
-if (strlen(token) && (up->defined || tk->defined))
+if (strlen(token))
 {
-/* auth-token has no password, so it needs the username
- * either already set or copied from up */
 strncpynt(tk->password, token, USER_PASS_LEN);
-if (up->defined)
+tk->token_defined = true;
+
+/*
+ * --auth-token has no username, so it needs the username
+ * either already set or copied from up, or later set by
+ * --auth-token-user
+ *
+ * Do not overwrite the username if already set to avoid
+ * overwriting an auth-token
+ */
+if (up->defined && !tk->defined)
 {
 strncpynt(tk->username, up->username, USER_PASS_LEN);
+tk->defined = true;
 }
-tk->defined = true;
 }
 
 /* Cleans user/pass for nocache */
 purge_user_pass(up, false);
 }
 
+void
+set_auth_token_user(struct user_pass *tk, const char *username)
+{
+if (strlen(username))
+{
+/* Clear the username before decoding to ensure no old material is left
+ * and also allow decoding to not use all space to ensure the last 
byte is
+ * always 0 */
+CLEAR(tk->username);
+int len = openvpn_base64_decode(username, tk->username, USER_PASS_LEN 
- 1);
+tk->defined = len > 0;
+if (!tk->defined)
+{
+msg(D_PUSH, "Error decoding auth-token-username");
+}
+}
+}
+
+
 /*
  * Process string received by untrusted peer before
  * printing to console or log file.
diff --git a/src/openvpn/misc.h b/src/openvpn/misc.h
index d9005353e..0d2d42489 100644
--- a/src/openvpn/misc.h
+++ b/src/openvpn/misc.h
@@ -56,6 +56,9 @@ const char *hostname_randomize(const char *hostname, struct 
gc_arena *gc);
 struct user_pass
 {
 bool defined;
+/* For auth-token username and token can be set individually, so
+ * we this second bool to track if the token (password) is defined */
+bool token_defined;
 bool nocache;
 
 /* max length of username/password */
@@ -138,19 +141,31 @@ void fail_user_pass(const char *prefix,
 void purge_user_pass(struct user_pass *up, const bool force);
 
 /**
- * Sets the auth-token to token if a username is available from either
- * up or already present in tk. The method will also purge up if
+ * Sets the auth-token to token. Ff a username is available from either
+ * up or already present in tk is the auth-token that will be used as default
+ * username for the token. The method will also purge up if
  * the auth-nocache option is active.
  *
  * @param up(non Auth-token) Username/password
  * @param tkauth-token userpass to set
- * @param token token to use as password for the
+ * @param token token to use as password for the auth-token
  *
  * @noteall parameters to this function must not be null.
  */
 void set_auth_token(struct user_pass *up, struct user_pass *tk,
 const

[Openvpn-devel] [PATCH v2 8/9] Remove --ncp-disable option

2021-05-20 Thread Arne Schwabe

NCP has proven to be stable and apart from the one VPN Provider doing
hacky things with homebrewed NCP we have not had any reports about
ncp-disable being required. Remove ncp-disable to simplify code paths.

Note: This patch breaks client without --pull. The follow up patch
for P2P NCP will restore that. But to avoid all the NCP/non-NCP special
cases to be implemented in P2P. P2P will directly switch from always
non-NCP to always NCP.

Signed-off-by: Arne Schwabe 
---
 Changes.rst   |  4 +++
 doc/man-sections/protocol-options.rst |  8 ++
 src/openvpn/init.c| 17 -
 src/openvpn/multi.c   |  4 ---
 src/openvpn/options.c | 36 +++
 src/openvpn/options.h |  1 -
 src/openvpn/ssl.c |  3 +--
 src/openvpn/ssl_common.h  |  1 -
 src/openvpn/ssl_ncp.c |  4 ---
 9 files changed, 16 insertions(+), 62 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 9185b55f7..e7ae6abed 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -57,6 +57,10 @@ Deprecated features
 is considered "too complicated", using ``--peer-fingerprint`` makes
 TLS mode about as easy as using ``--secret``.
 
+``ncp-disable`` has been removed
+This option mainly served a role as debug option when NCP was first
+introduced. It should now no longer be necessary.
+
 Overview of changes in 2.5
 ==
 
diff --git a/doc/man-sections/protocol-options.rst 
b/doc/man-sections/protocol-options.rst
index 34d4255ee..5ae780e1f 100644
--- a/doc/man-sections/protocol-options.rst
+++ b/doc/man-sections/protocol-options.rst
@@ -65,8 +65,8 @@ configured in a compatible way between both the local and 
remote side.
   The default is :code:`BF-CBC`, an abbreviation for Blowfish in Cipher
   Block Chaining mode. When cipher negotiation (NCP) is allowed,
   OpenVPN 2.4 and newer on both client and server side will automatically
-  upgrade to :code:`AES-256-GCM`.  See ``--data-ciphers`` and
-  ``--ncp-disable`` for more details on NCP.
+  upgrade to :code:`AES-256-GCM`.  See ``--data-ciphers`` for more details
+  on NCP.
 
   Using :code:`BF-CBC` is no longer recommended, because of its 64-bit
   block size. This small block size allows attacks based on collisions, as
@@ -235,10 +235,6 @@ configured in a compatible way between both the local and 
remote side.
 have been configured with `--enable-small`
 (typically used on routers or other embedded devices).
 
---ncp-disable
-  **DEPRECATED** Disable "Negotiable Crypto Parameters". This completely
-  disables cipher negotiation.
-
 --secret args
   **DEPRECATED** Enable Static Key encryption mode (non-TLS). Use pre-shared 
secret
   ``file`` which was generated with ``--genkey``.
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 4335d4870..38abf9f3a 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2227,18 +2227,14 @@ pull_permission_mask(const struct context *c)
 | OPT_P_EXPLICIT_NOTIFY
 | OPT_P_ECHO
 | OPT_P_PULL_MODE
-| OPT_P_PEER_ID;
+| OPT_P_PEER_ID
+| OPT_P_NCP;
 
 if (!c->options.route_nopull)
 {
 flags |= (OPT_P_ROUTE | OPT_P_IPWIN32);
 }
 
-if (c->options.ncp_enabled)
-{
-flags |= OPT_P_NCP;
-}
-
 return flags;
 }
 
@@ -2720,8 +2716,6 @@ do_init_crypto_tls_c1(struct context *c)
 *
 * Therefore, the key structure has to be initialized when:
 * - any non-BF-CBC cipher was selected; or
-* - BF-CBC is selected and NCP is disabled (explicit request to
-*   use the BF-CBC cipher); or
 * - BF-CBC is selected, NCP is enabled and fallback is enabled
 *   (BF-CBC will be the fallback).
 * - BF-CBC is in data-ciphers and we negotiate to use BF-CBC:
@@ -2731,12 +2725,12 @@ do_init_crypto_tls_c1(struct context *c)
 * Note that BF-CBC will still be part of the OCC string to retain
 * backwards compatibility with older clients.
 */
-if (!streq(options->ciphername, "BF-CBC") || !options->ncp_enabled
-|| (options->ncp_enabled && tls_item_in_cipher_list("BF-CBC", 
options->ncp_ciphers))
+if (!streq(options->ciphername, "BF-CBC")
+|| tls_item_in_cipher_list("BF-CBC", options->ncp_ciphers)
 || options->enable_ncp_fallback)
 {
 /* Do not warn if the if the cipher is used only in OCC */
-bool warn = !options->ncp_enabled || options->enable_ncp_fallback;
+bool warn = options->enable_ncp_fallback;
 init_key_type(>c1.ks.key_type, options->ciphername, 
options->authname,
   true, warn);
 }
@@ -2838,7 +2832,6 @@ do_init_crypto_tls(struct context *c, const unsigned int 
flags)
 to.tcp_mode = link_socket_proto_connection_oriented(options->ce.proto);
 to.config_ciphername =

[Openvpn-devel] [PATCH v2 3/9] Add connection_established as state in tls_multi->context_auth

2021-05-20 Thread Arne Schwabe

the socket_info->connection_establish is set through
link_socket_set_outgoing_addr when we reach FULL_SYNC. This patch
introduces a new state in context_auth that replaces the
connection_established state for TLS connections. This make the state
machine easier to understand.

Patch v2: fix p2p mode server without (without ncp)

Signed-off-by: Arne Schwabe 
---
 src/openvpn/forward.c|  6 +++---
 src/openvpn/forward.h| 13 -
 src/openvpn/multi.c  | 15 ---
 src/openvpn/occ.c|  2 +-
 src/openvpn/openvpn.h|  4 +++-
 src/openvpn/push.c   |  2 +-
 src/openvpn/ssl.c| 38 --
 src/openvpn/ssl_common.h | 12 +---
 8 files changed, 65 insertions(+), 27 deletions(-)

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index e302d8e0a..692ca7271 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -280,7 +280,7 @@ void
 check_connection_established(struct context *c)
 {
 
-if (CONNECTION_ESTABLISHED(c))
+if (connection_established(c))
 {
 /* if --pull was specified, send a push request to server */
 if (c->c2.tls_multi && c->options.pull)
@@ -536,7 +536,7 @@ encrypt_sign(struct context *c, bool comp_frag)
  * has not yet succeeded. In non-TLS tls_multi mode is not defined
  * and we always pass packets.
  */
-if (c->c2.tls_multi && c->c2.tls_multi->multi_state != CAS_SUCCEEDED)
+if (c->c2.tls_multi && c->c2.tls_multi->multi_state < CAS_CONNECT_DONE)
 {
 c->c2.buf.len = 0;
 }
@@ -971,7 +971,7 @@ process_incoming_link_part1(struct context *c, struct 
link_socket_info *lsi, boo
  * has not yet succeeded. In non-TLS mode tls_multi is not defined
  * and we always pass packets.
  */
-if (c->c2.tls_multi && c->c2.tls_multi->multi_state != CAS_SUCCEEDED)
+if (c->c2.tls_multi && c->c2.tls_multi->multi_state < CAS_CONNECT_DONE)
 {
 c->c2.buf.len = 0;
 }
diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h
index 2a67c1445..3461e6422 100644
--- a/src/openvpn/forward.h
+++ b/src/openvpn/forward.h
@@ -445,6 +445,17 @@ io_wait(struct context *c, const unsigned int flags)
 }
 }
 
-#define CONNECTION_ESTABLISHED(c) 
(get_link_socket_info(c)->connection_established)
+static inline bool
+connection_established(struct context *c)
+{
+if (c->c2.tls_multi)
+{
+return c->c2.tls_multi->multi_state >= CAS_CONNECT_DONE;
+}
+else
+{
+return get_link_socket_info(c)->connection_established;
+}
+}
 
 #endif /* FORWARD_H */
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index def5dd40b..3f9710134 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -674,7 +674,8 @@ multi_close_instance(struct multi_context *m,
 #ifdef ENABLE_MANAGEMENT
 set_cc_config(mi, NULL);
 #endif
-if (mi->context.c2.tls_multi->multi_state == CAS_SUCCEEDED)
+
+if (mi->context.c2.tls_multi->multi_state >= CAS_CONNECT_DONE)
 {
 multi_client_disconnect_script(mi);
 }
@@ -775,7 +776,7 @@ multi_create_instance(struct multi_context *m, const struct 
mroute_addr *real)
 goto err;
 }
 
-mi->context.c2.tls_multi->multi_state = CAS_PENDING;
+mi->context.c2.tls_multi->multi_state = CAS_NOT_CONNECTED;
 
 if (hash_n_elements(m->hash) >= m->max_clients)
 {
@@ -2407,7 +2408,7 @@ multi_client_connect_late_setup(struct multi_context *m,
 mi->reporting_addr_ipv6 = mi->context.c2.push_ifconfig_ipv6_local;
 
 /* set context-level authentication flag */
-mi->context.c2.tls_multi->multi_state = CAS_SUCCEEDED;
+mi->context.c2.tls_multi->multi_state = CAS_CONNECT_DONE;
 
 /* authentication complete, calculate dynamic client specific options */
 if (!multi_client_set_protocol_options(>context))
@@ -2649,9 +2650,9 @@ multi_connection_established(struct multi_context *m, 
struct multi_instance *mi)
 
 case CC_RET_DEFERRED:
 /*
- * we already set client_connect_status to DEFERRED_RESULT or
+ * we already set multi_status to DEFERRED_RESULT or
  * DEFERRED_NO_RESULT. We just return
- * from the function as having client_connect_status
+ * from the function as having multi_status
  */
 return;
 
@@ -3003,8 +3004,8 @@ multi_process_post(struct multi_context *m, struct 
multi_instance *mi, const uns
 {
 /* connection is "established" when SSL/TLS key negotiation 
succeeds
  * and (if specified) auth user/pass succeeds */
-if (is_cas_pending(mi->context.c2.tls_multi->multi_state)
-&& CONNECTION_ESTABLISHED(>context))
+
+if (is_cas_pending(mi->context.c2.tls_multi->multi_state))
 {
 multi_connection_established(m, mi);
 }
diff --git a/src/openvpn/occ.c

[Openvpn-devel] [PATCH v2 5/9] Extracting key_state deferred auth status update into function

2021-05-20 Thread Arne Schwabe

This extract the update of a deferred key status into into own
function.

Patch v2: Do not ignore auth_deferred_expire. Minor format changes.

Signed-off-by: Arne Schwabe 
---
 src/openvpn/ssl_verify.c | 96 ++--
 1 file changed, 62 insertions(+), 34 deletions(-)

diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index 7992a6eb9..455a5cd1b 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1073,6 +1073,60 @@ key_state_test_auth_control_file(struct 
auth_deferred_status *ads, bool cached)
 return ACF_DISABLED;
 }
 
+/**
+ * This method takes a key_state and if updates the state
+ * of the key if it is deferred.
+ * @param cachedIf auth control files should be tried to be opened or th
+ *  cached results should be used
+ * @param ksThe key_state to update
+ */
+static void
+update_key_auth_status(bool cached, struct key_state *ks)
+{
+if (ks->authenticated == KS_AUTH_FALSE)
+{
+return;
+}
+else
+{
+enum auth_deferred_result auth_plugin = ACF_DISABLED;
+enum auth_deferred_result auth_script = ACF_DISABLED;
+enum auth_deferred_result auth_man = ACF_DISABLED;
+auth_plugin = key_state_test_auth_control_file(>plugin_auth, 
cached);
+auth_script = key_state_test_auth_control_file(>script_auth, 
cached);
+#ifdef ENABLE_MANAGEMENT
+auth_man = man_def_auth_test(ks);
+#endif
+ASSERT(auth_plugin < 4 && auth_script < 4 && auth_man < 4);
+
+if (auth_plugin == ACF_FAILED || auth_script == ACF_FAILED
+   || auth_man == ACF_FAILED)
+{
+ks->authenticated = KS_AUTH_FALSE;
+return;
+}
+else if (auth_plugin == ACF_PENDING || auth_script == ACF_PENDING
+ || auth_man == ACF_PENDING)
+{
+if (now > ks->auth_deferred_expire)
+{
+/* Window to authenticate the key has expired, mark
+ * the key as unauthenticated */
+ks->authenticated = KS_AUTH_FALSE;
+}
+}
+else
+{
+/* all auth states (auth_plugin, auth_script, auth_man)
+ * are either ACF_DISABLED or ACF_SUCCEDED now, which
+ * translates to "not checked" or "auth succeeded"
+ */
+ks->authenticated = KS_AUTH_TRUE;
+}
+}
+}
+
+
 /**
  * The minimum times to have passed to update the cache. Older versions
  * of OpenVPN had code path that did not do any caching, so we start
@@ -1115,46 +1169,20 @@ tls_authentication_status(struct tls_multi *multi)
 if (TLS_AUTHENTICATED(multi, ks))
 {
 active++;
+update_key_auth_status(cached, ks);
+
 if (ks->authenticated == KS_AUTH_FALSE)
 {
 failed_auth = true;
 }
-else
+else if (ks->authenticated == KS_AUTH_DEFERRED)
 {
-enum auth_deferred_result auth_plugin = ACF_DISABLED;
-enum auth_deferred_result auth_script = ACF_DISABLED;
-enum auth_deferred_result auth_man = ACF_DISABLED;
-auth_plugin = 
key_state_test_auth_control_file(>plugin_auth, cached);
-auth_script = 
key_state_test_auth_control_file(>script_auth, cached);
-#ifdef ENABLE_MANAGEMENT
-auth_man = man_def_auth_test(ks);
-#endif
-ASSERT(auth_plugin < 4 && auth_script < 4 && auth_man < 4);
 
-if (auth_plugin == ACF_FAILED || auth_script == ACF_FAILED
-   || auth_man == ACF_FAILED)
-{
-ks->authenticated = KS_AUTH_FALSE;
-failed_auth = true;
-}
-else if (auth_plugin == ACF_PENDING
- || auth_script == ACF_PENDING
- || auth_man == ACF_PENDING)
-{
-if (now < ks->auth_deferred_expire)
-{
-deferred = true;
-}
-}
-else
-{
-/* all auth states (auth_plugin, auth_script, auth_man)
- * are either ACF_DISABLED or ACF_SUCCEDED now, which
- * translates to "not checked" or "auth succeeded"
- */
-success = true;
-ks->authenticated = KS_AUTH_TRUE;
-}
+deferred = true;
+}
+else if (ks->authenticated == KS_AUTH_TRUE)
+{
+success = true;
 }
 }
 }
-- 
2.31.1



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

[Openvpn-devel] [PATCH v2 7/9] Move auth_token_state_flags to tls_session and cleanup initial_token

2021-05-20 Thread Arne Schwabe

The usage of the auth_token_state_flags is tied to the authentication.
The other authentication related flags and status are in the
tls_session struct instead of the tls_multi struct. Move
auth_token_state_flags to the right place.

This also changes that auth_token_initial is set when the token is
initially generated instead when pushing the token. Even I don't know
anymore why I did it in this way in the first place. Also use
multi->auth_token_initial as source for the sesssion ID since it should
now always be available.

Signed-off-by: Arne Schwabe 
---
 src/openvpn/auth_token.c   | 28 +++---
 src/openvpn/push.c |  8 ---
 src/openvpn/ssl_verify.c   |  5 +++-
 tests/unit_tests/openvpn/test_auth_token.c | 15 
 4 files changed, 35 insertions(+), 21 deletions(-)

diff --git a/src/openvpn/auth_token.c b/src/openvpn/auth_token.c
index 0ea6d1832..60604e6e3 100644
--- a/src/openvpn/auth_token.c
+++ b/src/openvpn/auth_token.c
@@ -109,11 +109,11 @@ add_session_token_env(struct tls_session *session, struct 
tls_multi *multi,
 /*
  * No session before, generate a new session token for the new session
  */
-if (!multi->auth_token)
+if (!multi->auth_token_initial)
 {
 generate_auth_token(up, multi);
 }
-session_id_source = multi->auth_token;
+session_id_source = multi->auth_token_initial;
 }
 /*
  * In the auth-token the auth token is already base64 encoded
@@ -184,7 +184,7 @@ generate_auth_token(const struct user_pass *up, struct 
tls_multi *multi)
 
 uint8_t sessid[AUTH_TOKEN_SESSION_ID_LEN];
 
-if (multi->auth_token)
+if (multi->auth_token_initial)
 {
 /* Just enough space to fit 8 bytes+ 1 extra to decode a non padded
  * base64 string (multiple of 3 bytes). 9 bytes => 12 bytes base64
@@ -192,13 +192,18 @@ generate_auth_token(const struct user_pass *up, struct 
tls_multi *multi)
  */
 char old_tstamp_decode[9];
 
+/* Make a copy of the string to not modify multi->auth_token_initial */
+char* initial_token_copy = string_alloc(multi->auth_token_initial, 
);
+
 /*
  * reuse the same session id and timestamp and null terminate it at
  * for base64 decode it only decodes the session id part of it
  */
-char *old_sessid = multi->auth_token + strlen(SESSION_ID_PREFIX);
+char *old_sessid =initial_token_copy + strlen(SESSION_ID_PREFIX);
 char *old_tsamp_initial = old_sessid + AUTH_TOKEN_SESSION_ID_LEN*8/6;
 
+
+
 old_tsamp_initial[12] = '\0';
 ASSERT(openvpn_base64_decode(old_tsamp_initial, old_tstamp_decode, 9) 
== 9);
 
@@ -212,10 +217,6 @@ generate_auth_token(const struct user_pass *up, struct 
tls_multi *multi)
 
 old_tsamp_initial[0] = '\0';
 ASSERT(openvpn_base64_decode(old_sessid, sessid, 
AUTH_TOKEN_SESSION_ID_LEN)==AUTH_TOKEN_SESSION_ID_LEN);
-
-
-/* free the auth-token, we will replace it with a new one */
-free(multi->auth_token);
 }
 else if (!rand_bytes(sessid, AUTH_TOKEN_SESSION_ID_LEN))
 {
@@ -272,11 +273,22 @@ generate_auth_token(const struct user_pass *up, struct 
tls_multi *multi)
 
 free(b64output);
 
+/* free the auth-token if defined, we will replace it with a new one */
+free(multi->auth_token);
 multi->auth_token = strdup((char *)BPTR(_token));
 
 dmsg(D_SHOW_KEYS, "Generated token for client: %s (%s)",
  multi->auth_token, up->username);
 
+if (!multi->auth_token_initial)
+{
+/*
+ * Save the initial auth token for clients that ignore
+ * the updates to the token
+ */
+multi->auth_token_initial = strdup(multi->auth_token);
+}
+
 gc_free();
 }
 
diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index 2d621e472..98a9c3689 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -527,14 +527,6 @@ prepare_auth_token_push_reply(struct tls_multi *tls_multi, 
struct gc_arena *gc,
 push_option_fmt(gc, push_list, M_USAGE,
 "auth-token %s",
 tls_multi->auth_token);
-if (!tls_multi->auth_token_initial)
-{
-/*
- * Save the initial auth token for clients that ignore
- * the updates to the token
- */
-tls_multi->auth_token_initial = strdup(tls_multi->auth_token);
-}
 }
 }
 
diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index 455a5cd1b..dfb475017 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1512,6 +1512,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
*multi,
  */
 if (session->opt->auth_token_generate && is_auth_token(up->password))
 {
+
 ks->auth_token_state_flags = verify_auth_token(up, multi, session);
 if

[Openvpn-devel] [PATCH v2 4/9] Make waiting on auth an explicit state in the context state machine

2021-05-20 Thread Arne Schwabe

Previously we relied on checking tls_authentication_status to check
wether to determine if the context auth state is actually valid or not.
This patch eliminates that check by introducing waiting on the
authentication as extra state in the context auth, state machine.

Signed-off-by: Arne Schwabe 
---
 src/openvpn/multi.c  | 5 -
 src/openvpn/ssl.c| 9 -
 src/openvpn/ssl_common.h | 1 +
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 3f9710134..7cb9e86aa 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2596,11 +2596,6 @@ static const multi_client_connect_handler 
client_connect_handlers[] = {
 static void
 multi_connection_established(struct multi_context *m, struct multi_instance 
*mi)
 {
-if (tls_authentication_status(mi->context.c2.tls_multi) != 
TLS_AUTHENTICATION_SUCCEEDED)
-{
-return;
-}
-
 /* We are only called for the CAS_PENDING_x states, so we
  * can ignore other states here */
 bool from_deferred = (mi->context.c2.tls_multi->multi_state != 
CAS_PENDING);
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 9f3f83f16..fd64b8d4e 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2810,7 +2810,7 @@ tls_process(struct tls_multi *multi,
 if (session->opt->mode == MODE_SERVER)
 {
 /* On a server we continue with running connect 
scripts next */
-multi->multi_state = CAS_PENDING;
+multi->multi_state = CAS_WAITING_AUTH;
 }
 else
 {
@@ -3136,6 +3136,13 @@ tls_multi_process(struct tls_multi *multi,
 
 enum tls_auth_status tas = tls_authentication_status(multi);
 
+/* If we have successfully authenticated and are still waiting for the 
authentication to finish
+ * move the state machine for the multi context forward */
+if (multi->multi_state == CAS_WAITING_AUTH && tas == 
TLS_AUTHENTICATION_SUCCEEDED)
+{
+multi->multi_state = CAS_PENDING;
+}
+
 /*
  * If lame duck session expires, kill it.
  */
diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
index 8a65ab984..66700bf68 100644
--- a/src/openvpn/ssl_common.h
+++ b/src/openvpn/ssl_common.h
@@ -511,6 +511,7 @@ struct tls_session
  * connect scripts/plugins */
 enum multi_status {
 CAS_NOT_CONNECTED,
+CAS_WAITING_AUTH,   /**< TLS connection established but 
deferred auth not finished */
 CAS_PENDING,
 CAS_PENDING_DEFERRED,
 CAS_PENDING_DEFERRED_PARTIAL,   /**< at least handler succeeded, no result 
yet*/
-- 
2.31.1



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

[Openvpn-devel] [PATCH v2 6/9] Introduce S_GENERATED_KEYS state and generate keys only when authenticated

2021-05-20 Thread Arne Schwabe

Since generating data channel keys does not happen when we have reach the
S_ACTIVE/S_GOT_KEY state anymore like it used to be before NCP, the
state that data channel keys deserves its own state in the TLS session
state machine.

The changes done by this commit are rather intrusive since they
move the key generation to a completely different place and also
rely on the state machine to decide if keys should be
generated rather than on the complicated conditions that were
implemented in the key_method_2_write/read methods.

A (intended) side effect of this change is that sessions that
are still in deferred state (ks->authenticated == KS_DEFERRED)
will not have data channel keys generated. This avoids corner
cases where a not fully authenticated sessions might leak data.

Signed-off-by: Arne Schwabe 

Patch v2: rebased

Signed-off-by: Arne Schwabe 
---
 src/openvpn/forward.h|  2 +-
 src/openvpn/init.c   |  1 +
 src/openvpn/ssl.c| 89 +---
 src/openvpn/ssl.h| 10 +
 src/openvpn/ssl_common.h |  9 +++-
 5 files changed, 57 insertions(+), 54 deletions(-)

diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h
index 3461e6422..b8760099e 100644
--- a/src/openvpn/forward.h
+++ b/src/openvpn/forward.h
@@ -450,7 +450,7 @@ connection_established(struct context *c)
 {
 if (c->c2.tls_multi)
 {
-return c->c2.tls_multi->multi_state >= CAS_CONNECT_DONE;
+return c->c2.tls_multi->multi_state >= CAS_WAITING_OPTIONS_IMPORT;
 }
 else
 {
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 49c742928..4335d4870 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2202,6 +2202,7 @@ do_up(struct context *c, bool pulled_options, unsigned 
int option_types_found)
 }
 
 c->c2.do_up_ran = true;
+c->c2.tls_multi->multi_state = CAS_CONNECT_DONE;
 }
 return true;
 }
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index fd64b8d4e..b28d8edf8 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -788,6 +788,9 @@ state_name(int state)
 case S_ERROR:
 return "S_ERROR";
 
+case S_GENERATED_KEYS:
+return "S_GENERATED_KEYS";
+
 default:
 return "S_???";
 }
@@ -1840,13 +1843,13 @@ key_ctx_update_implicit_iv(struct key_ctx *ctx, uint8_t 
*key, size_t key_len)
  * This erases the source material used to generate the data channel keys, and
  * can thus be called only once per session.
  */
-static bool
+bool
 tls_session_generate_data_channel_keys(struct tls_session *session)
 {
 bool ret = false;
 struct key_state *ks = >key[KS_PRIMARY];   /* primary key */
 
-if (ks->authenticated == KS_AUTH_FALSE)
+if (ks->authenticated <= KS_AUTH_FALSE)
 {
 msg(D_TLS_ERRORS, "TLS Error: key_state not authenticated");
 goto cleanup;
@@ -1862,6 +1865,9 @@ tls_session_generate_data_channel_keys(struct tls_session 
*session)
 tls_limit_reneg_bytes(session->opt->key_type.cipher,
   >opt->renegotiate_bytes);
 
+/* set the state of the keys for the session to generated */
+ks->state = S_GENERATED_KEYS;
+
 ret = true;
 cleanup:
 secure_memzero(ks->key_src, sizeof(*ks->key_src));
@@ -2375,31 +2381,6 @@ key_method_2_write(struct buffer *buf, struct tls_multi 
*multi, struct tls_sessi
 goto error;
 }
 
-/*
- * 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_CONNECT_DONE status is identical to
- * NCP options are processed and do not wait for NCP being finished.
- */
-if (ks->authenticated > KS_AUTH_FALSE && session->opt->server
-&& ((session->opt->mode == MODE_SERVER && multi->multi_state >= 
CAS_CONNECT_DONE)
-|| (session->opt->mode == MODE_POINT_TO_POINT && 
!session->opt->pull)))
-{
-/* if key_id >= 1, is a renegotiation, so we use the already 
established
- * parameters and do not need to delay anything. */
-
-/* key-id == 0 and multi_state >= CAS_CONNECT_DONE is a special case of
- * the server reusing the session of a reconnecting client. */
-if (!tls_session_generate_data_channel_keys(session))
-{
-msg(D_TLS_ERRORS, "TLS Error: server generate_key_expansion 
failed");
-goto error;
-}
-}
-
 return true;
 
 error:
@@ -2599,21 +2580,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
*multi, struct tls_sessio
 
 setenv_del(session->opt->es, "exported_keying_material");
 }
-
-/*
- * Generate tunnel keys if we're a client.
- * If --pull is enabled, the first key generation is postponed until after 
the
- * pull/push, so we can process

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

[Openvpn-devel] [PATCH] openvpnmsica: add ovpn-dco custom actions

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

[Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint

[Openvpn-devel] [PATCH v2 1/2] Move examples into openvpn-examples(5) man page

[Openvpn-devel] [PATCH v2 1/9] Move auth_token_state from multi to key_state

[Openvpn-devel] [PATCH v2 9/9] Support NCP in pure P2P VPN setups

[Openvpn-devel] [PATCH v2 2/9] Implement auth-token-user

[Openvpn-devel] [PATCH v2 8/9] Remove --ncp-disable option

[Openvpn-devel] [PATCH v2 3/9] Add connection_established as state in tls_multi->context_auth

[Openvpn-devel] [PATCH v2 5/9] Extracting key_state deferred auth status update into function

[Openvpn-devel] [PATCH v2 7/9] Move auth_token_state_flags to tls_session and cleanup initial_token

[Openvpn-devel] [PATCH v2 4/9] Make waiting on auth an explicit state in the context state machine

[Openvpn-devel] [PATCH v2 6/9] Introduce S_GENERATED_KEYS state and generate keys only when authenticated

24 matches

Site Navigation

Mail list logo

Footer information