NetworkManager-openvpn merge requestshttps://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests2024-01-25T16:14:02Zhttps://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/73auth-dialog: assume encrypted key file if the file can't be read2024-01-25T16:14:02ZMartin Wilckauth-dialog: assume encrypted key file if the file can't be readFor openvpn with TLS and password, `get_passwords_required()` checks
if the key file is encrypted. If the key file can't be opened
(e.g. because it's owned by root with permissions 0600),
`is_encrypted()` returns FALSE. The user will not...For openvpn with TLS and password, `get_passwords_required()` checks
if the key file is encrypted. If the key file can't be opened
(e.g. because it's owned by root with permissions 0600),
`is_encrypted()` returns FALSE. The user will not be asked for
a certificate password in this case, making it impossible to connect,
and be left clueless about the reason.
If the keyfile is not readable, print an error message and assume
that the password is required. While the error message will only be observed
by nmcli users, this will allow users with encrypted keys to activate
their connection. Users with unencrypted keys can just enter anything
into the 2nd password prompt and will still be able to connect. Such
users might be confused, but this is better than not being able to
connect at all.
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1384https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/71Update conflicting mnemonics and add missing ones to Identity - Advanced view2023-10-03T14:13:14ZBalázs ÚrUpdate conflicting mnemonics and add missing ones to Identity - Advanced viewIn the Identity -> Advanced... screen, some mnemonics are conflicting with others and some mnemonics are missing. Here is a summary what I propose to change, where:
- `(mod)` means, it is changed to letter in the first position (the ori...In the Identity -> Advanced... screen, some mnemonics are conflicting with others and some mnemonics are missing. Here is a summary what I propose to change, where:
- `(mod)` means, it is changed to letter in the first position (the original is what is underscored)
- `(new)` means, it was missing and added now
- `<empty>` means, no change.
General
```
O Use custom gateway p_ort
R Use custom _renegotiation interval
D (mod) Data _compression
T Use a _TCP connection
V (mod) Set virtual _device type
N and _name
U Use custom tunnel Maximum Transmission _Unit (MTU)
F Use custom UDP _fragment size
S Restrict tunnel TCP Maximum _Segment Size (MSS)
M Rando_mize remote hosts
W (new) Allow Pull FQDN
P _Prefix remote DNS name with random string
I (new) IPv6 tun link
G Specify pin_g interval
E Specify _exit or restart ping
L Accept authenticated packets from any address (F_loat)
X (new) Specify max routes
```
Security
```
P Ci_pher
S Use custom _size of cipher key
H _HMAC Authentication
F (new) Verify CRL from file
D (new) Verify CRL from directory
N Disable cipher _negotiation
```
TLS Authentication
```
I (mod) Server _Certificate Check
S _Subject Match
U (mod) _Verify peer (server) certificate usage signature
T (mod) _Remote peer certificate TLS type
V _Verify peer (server) certificate nsCertType designation
R _Remote peer certificate nsCert designation
M (new) Mode
F Key _File
D Key _Direction
E (new) Extra Certificates
P (new) TLS cipher string
N (mod) TLS _min version
X TLS ma_x version
O _or highest
```
Proxies
```
T Proxy _Type
E (mod) Server _Address
P _Port
R _Retry indefinitely when errors occur
U Proxy _Username
D Proxy Passwor_d
S _Show password
```
Misc
```
D (new) Path mtu discovery
T (new) Connect timeout
P (new) Push peer info
```https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/70Added support for 'data-ciphers-fallback' option2023-10-08T14:11:46ZJakub StrnadAdded support for 'data-ciphers-fallback' optionHello, this is my first merge request to this project, so please forgive if I am unfamiliar with the process or missed some steps.
Motivation for merge request:
The current behavior is that .ovpn files with data-ciphers-fallback work fi...Hello, this is my first merge request to this project, so please forgive if I am unfamiliar with the process or missed some steps.
Motivation for merge request:
The current behavior is that .ovpn files with data-ciphers-fallback work fine if run via openvpn cli, but fail or are ignored when run via NetworkManager.
Therefore I added support for .ovpn config option `data-ciphers-fallback`, so that when an .ovpn file has this option, it is read, parsed and used by NetworkManager. If the changes made here are not present, the option either doesn't get parsed, or it crashes with a BadArgument error if it is added manually to the .nmconnection file.
Changes:
Added parsing support for data-ciphers-fallback wherever applicable, modified tests to include check for this option (albeit, null).
Questions:
What should I do with the `.po` files? Should I also include them in the merge request? Will they be fine as they are regenerated, or they require more work?
Thanks,
Jakubhttps://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/68Add compat-mode option2023-08-28T12:56:16ZIvan KrasnovAdd compat-mode optionPartially resolves #97 in my case, as supplying data-ciphers field and compat-mode 2.3.0 fixes an issue of not being able to connect to old openvpn servers.
Tested only on 2.3.0ish server.
nm-applet overwrites these changes, sadly. nmc...Partially resolves #97 in my case, as supplying data-ciphers field and compat-mode 2.3.0 fixes an issue of not being able to connect to old openvpn servers.
Tested only on 2.3.0ish server.
nm-applet overwrites these changes, sadly. nmcli does not.
# MR changes
Adds an option to supply a compat-mode parameter on ovpn file import, that will be passed to openvpn on connection.
# How to test
The following is required:
1. OpenVPN server 2.3.0 or older.
2. Compiled and installed NetworkManager-openvpn plugin
...https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/67Add pkcs#11 support with tls-auth option2024-02-09T10:40:01ZAnton KAdd pkcs#11 support with tls-auth optionThis merge request is based on https://gitlab.gnome.org/heyLu/NetworkManager-openvpn/-/merge_requests/2.
It allows using PKCS#11 tokens and adds two new connection types.
The issues with original MR were:
* TLS Authentication tab is mis...This merge request is based on https://gitlab.gnome.org/heyLu/NetworkManager-openvpn/-/merge_requests/2.
It allows using PKCS#11 tokens and adds two new connection types.
The issues with original MR were:
* TLS Authentication tab is missing in Advanced Setting
* Authentication Type names don't match settings behind it
I haven't found any style guides or linters. Thus, provide MR as is.
### Motivation
Secure storage of credentials can be archived in different ways with different security levels. One way is to store certificates and private keys for VPN on a hardware token.
Usually, tokens support a PKCS#11 interface. This MR adds ability to use it, additionally specifying a module with particular a PKCS#11 implementation.
### MR changes
The MR adds two new connection types:
* Certificates (TLS), PKCS#11
* Password with Certificates (TLS), PKCS#11
These connection types support new fields:
* PKCS#11 providers (rename to PKCS#11 provider?)
* PKCS#11 id
* PKCS#11 pin
If the field **PKCS#11 providers** is empty, p11-kit can be used.
### How to test
The following is required:
1) OpenVPN server
2) PKCS#11 token
3) Compiled and installed NetworkManager-openvpn plugin
To deploy an OpenVPN server you can use [this article](https://www.cyberciti.biz/faq/howto-setup-openvpn-server-on-ubuntu-linux-14-04-or-16-04-lts/). As a token emulator use [SoftHSM2](https://github.com/opendnssec/SoftHSMv2).
Assuming you have client's certificate (`cert.pem`) and key (`key.pem`) add them to the token this way:
```bash
LABEL=nm-openvpn-plugin-test
softhsm2-util --init-token --slot 0 --label ${LABEL}
TOKEN_URL=$(p11tool --list-tokens | grep ${LABEL} | grep URL | awk '{print $2}')
p11tool --login --write ${TOKEN_URL} --load-certificate cert.pem --label ovpn-test
p11tool --login --write ${TOKEN_URL} --load-privkey key.pem --label ovpn-test
```
To get PKCS#11 providers and id run the following commands:
```bash
PKCS11_MODULE=$(p11tool --list-tokens | grep libsofthsm2.so | awk '{print $2}')
echo "Provider: ${PKCS11_MODULE}"
echo -E "ID: $(openvpn --show-pkcs11-ids ${PKCS11_MODULE} | grep "Serialized id:" | awk '{print $3}')"
```
You must know PIN yourself.
Then create a new connection of type **Certificates (TLS), PKCS#11** and specify parameters. You're all set.
### Security considerations
As mentioned [in the comments](https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/67#note_1784990) to the MR, a user can elevate their privileges specifying arbitrary so-file. It works because an so-file is run with root privileges when the connection is activated.
To protect from this issue `NM_OPENVPN_PKCS11_PROVIDERS_PREFIX` was introduced effectively limiting available so-files. Thus, only root user can add new modules under `NM_OPENVPN_PKCS11_PROVIDERS_PREFIX`. It was considered a _good enough_ solution until [CVE-2023-38408](https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt). Now I see several possible solutions:
1) limit `NM_OPENVPN_PKCS11_PROVIDERS_PREFIX` even more (a bad one)
2) create symlinks to allowed modules/providers somewhere under `/etc/NetworkManager/` and use them
3) completely rely on p11-kit
The third solution seems to be the most robust. NetworkManager itself [behaves](https://wiki.gnome.org/Projects/NetworkManager/PKCS11) in a similar way.https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/55Add Meson support2022-08-29T17:27:08ZGhost UserAdd Meson supportThis commit adds Meson build files in hope for replacing the Autotools setup.This commit adds Meson build files in hope for replacing the Autotools setup.Lubomir RintelLubomir Rintelhttps://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/32Add support for PKCS#11 auth2023-02-28T09:54:31ZIgnat LoskutovAdd support for PKCS#11 authAdds support for new config options: `pkcs11-id` and `pkcs11-provider`,
which are then directly forwarded to OpenVPN.
`handle_auth` distinguishes PKCS#11 auth requests by the " token" suffix.
As other auth options currently supported don...Adds support for new config options: `pkcs11-id` and `pkcs11-provider`,
which are then directly forwarded to OpenVPN.
`handle_auth` distinguishes PKCS#11 auth requests by the " token" suffix.
As other auth options currently supported don't seem to operate with
tokens, this should work.
Another PKCS#11-specific aspect is forgetting the user-provided password
after forwarding it to OpenVPN, as password being re-asked usually means
that the one provided was rejected by the token
(PKCS#11 providers are not very good at error-reporting, at least not OpenSC).
I could get Yubikey working with a config similar to this:
```
[connection]
id=yubikey-auth-vpn
uuid=some-uuid-here
type=vpn
[vpn]
ca=/path/to/ca.pem
connection-type=pkcs11-tls
...
# agent-owned(0x1) | not-saved(0x2)
password-flags=3
pkcs11-id=piv_II/PKCS\\x2315\\x20emulated/...
pkcs11-provider=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
remote=my.vpn.com:443:udp
service-type=org.freedesktop.NetworkManager.openvpn
```