Server Validation Configuration Questions

Got a problem with Viscosity or need help? Ask here!

julienp

Posts: 1
Joined: Sat Nov 13, 2021 2:37 am

Post by julienp » Tue Nov 16, 2021 8:26 am
Hello,

Something strange came up using Viscosity for Mac 1.10.
It is related to a working configuration which has been fine for years and across Viscosity versions but I realise today a warning message I had overlooked since the beginning.

As I understand it the configuration is generated by the Viscosity application based on settings in the GUI.
And again the configuration works, the tunnel is established and connectivity via the tunnel is fine.

Now to the problem.
As I was attempting to configure openvpn clients running on Raspberry Pi, I thought I would reuse the openvpn configuration file generated by Viscosity to simplify the process but could not figure out why this copy-paste configuration just would not work... long story short, I realised that there is an error in the initial Viscosity client configuration file I tried using on the Raspberry Pi openvpn client... and the error makes any connection attempts from the Raspberry Pi openvpn client unsuccessful!

Just for information, on the Raspberry Pi openvpn clients, the errors are:
VERIFY EKU ERROR
OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

Now the configuration line which I see is problematic in the configuration file generated by the Viscosity client:
remote-cert-eku "TLS Web Client Authentication"

Indeed, this configuration line on any openvpn client should instead read:
remote-cert-eku "TLS Web Server Authentication"

Furthermore the client configuration should also read:
remote-cert-tls server
And that line is absent from the Viscosity client configuration file generated by Viscosity.

After looking at the Viscosity logs, I spotted that the log file shows "WARNING: No server certificate verification method has been enabled. " which probably explains the above configuration error, but still Viscosity establishes the connection! and that's why I never realised the configuration was not good.

On the openvpn forums I am told that it means the Viscosity client has a huge security bug, which I tend to agree with.
Indeed the Viscosity client should not connect to an unauthenticated server with no explicit override which evidently it does. Furthermore the Viscosity client should not generate such a configuration file to begin with.

Now I would also like to know if it is alright to manually modify the viscosity configuration file with the above changes and whether the viscosity client will use them?

And naturally would like your confirmation on the analysis of this problem and indication whether this will be fixed in a new release?

Configuration generated by the Viscosity client:

client
tls-client
ca ca.crt
cert client.crt
key client.key
tls-crypt myvpn.tlsauth
remote-cert-eku "TLS Web Client Authentication"
proto udp
remote openvpn_server_ip 1194 udp
dev tun
topology subnet
pull
user nobody
group nobody

Log file of a connection established by Viscosity:

2021-11-11 22:28:22: Viscosity Mac 1.10 (1582)
2021-11-11 22:28:22: Viscosity OpenVPN Engine Started
2021-11-11 22:28:22: Running on macOS 10.15.7
2021-11-11 22:28:22: ---------
2021-11-11 22:28:22: State changed to Connecting
2021-11-11 22:28:22: Checking reachability status of connection...
2021-11-11 22:28:23: Connection is reachable. Starting connection attempt.
2021-11-11 22:28:23: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2021-11-11 22:28:23: OpenVPN 2.5.4 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Oct 22 2021
2021-11-11 22:28:23: library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10
2021-11-11 22:28:23: Valid endpoint found: openvpn_server_ip:1194:udp
2021-11-11 22:28:23: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2021-11-11 22:28:23: TCP/UDP: Preserving recently used remote address: [AF_INET] openvpn_server_ip:1194
2021-11-11 22:28:23: UDP link local: (not bound)
2021-11-11 22:28:23: UDP link remote: [AF_INET]server_ip:1194
2021-11-11 22:28:23: State changed to Authenticating
2021-11-11 22:28:23: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1558'
2021-11-11 22:28:23: WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
2021-11-11 22:28:23: [server] Peer Connection Initiated with [AF_INET] openvpn_server_ip:1194
2021-11-11 22:28:23: WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2021-11-11 22:28:23: Opened utun device utun13
2021-11-11 22:28:23: /sbin/ifconfig utun13 delete
2021-11-11 22:28:23: NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2021-11-11 22:28:23: /sbin/ifconfig utun13 10.8.0.2 10.8.0.2 netmask 255.255.255.0 mtu 1500 up
2021-11-11 22:28:23: DNS mode set to Split
2021-11-11 22:28:23: DNS Server/s: 192.168.1.2
2021-11-11 22:28:23: DNS Domains/s: localdomain.local, sps.local
2021-11-11 22:28:23: WARNING: A .local domain is present in the DNS domain list. The .local domain is reserved for mDNS. Using it as a DNS domain may cause DNS resolution attempts to fail or unexpected DNS behaviour.
2021-11-11 22:28:24: State changed to Connected
2021-11-11 22:28:24: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2021-11-11 22:28:24: Initialization Sequence Completed

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Tue Nov 16, 2021 3:59 pm
Hi julienp,

So firstly, I've changed the title on your post from "major security bug on Viscosity client" to what it is now. We mean no offence by this change, however the previous title was incorrect and inflammatory.

The TLDR for any other Viscosity users coming across this post: this is not a security bug or vulnerability in Viscosity.

My apologies in advance for any bluntness in this post. We take security issues very seriously, so if a security claim is incorrect we need to be very clear in our wording why this is the case, especially when posted publicly where others will read it.

Please make sure you convey the information below to anywhere else you've posted this security claim to (you mention "openvpn forums"), as obviously having a claim that "the Viscosity client has a huge security bug" when that's not the case is highly damaging to Viscosity.

Issue 1

Now, you claim Viscosity has generated the command "remote-cert-eku "TLS Web Client Authentication"". This is not correct. Viscosity does not generate any "remote-cert-eku" commands at all, nor is there an option in the connection editor that corresponds to the "remote-cert-eku" command.

You've either imported a configuration into Viscosity with this command present, or you've added it yourself manually as an advanced command. Again, this command has not been generated or otherwise come from Viscosity. Claiming Viscosity has generated an insecure command for your setup is false.

Only you would know where it has come from. Importing a configuration file with it present is the most likely, as there are several other commands you have listed which Viscosity will never generate, including "client" (Viscosity uses "tls-client" and optionally "pull"), "topology subnet", "user nobody", and "group nobody".

As for who made that configuration file: again, only you would know. Perhaps you followed a server setup guide in the past that included a sample client configuration that you copied with these commands. Perhaps you used some server software or scripts that generated the configuration file for you. All we can say for sure is that it was not generated by Viscosity.

Issue 2

Next, you claim that Viscosity doesn't generate a "remote-cert-tls server" command. This is also false. Viscosity's connection editor has an option named "Require certificate was signed for server use" that corresponds to this command, and if ticked it is added to a configuration. If you import a configuration without the "remote-cert-tls server" command, then this option will obviously not appear selected in the connection editor.

The "Require certificate was signed for server use" option exists (rather than OpenVPN just applying it for all connections) as it's not suitable for all OpenVPN setups. Obviously if the server's certificate was generated without being explicitly marked for server-only use (by using the Extended key usage certificate extension) then you don't want this option enabled. Likewise some setups have the "server" and "client" reversed for whatever reason (as long as this is consistent across all servers/clients it is still secure).

Issue 3

Next, you've posted a copy of the configuration file you've claimed Viscosity has generated and using, however this is incorrect. As already explained above, this has not been generated by Viscosity because it contains commands Viscosity does not generate. You can also tell it's also not the configuration that your Viscosity VPN connection is actually using, as Viscosity removes some of these commands on import (such as the "user" and "group" commands - Viscosity instead uses a special sandboxed user).

Please view the Raw Configuration Data for your connection to view the actual configuration your VPN connection is using. You can also view/edit advanced commands (that there isn't an editor option for) under the Advanced Commands area. As an educated guess, I'd say the reason why your Viscosity connection is connecting, while your Raspberry Pi connection is not, as the "remote-cert-eku "TLS Web Client Authentication"" command isn't present in the configuration at all or has been changed. You may have manually removed it in the past to allow your VPN connection to connect or edited it.

Issue 4

Finally, you've said "Viscosity client should not connect to an unauthenticated server with no explicit override which evidently it does". This is incorrect. I don't think you understand what the options mentioned in your post are for or what they are doing. That's ok, understanding how this all works can be confusing, however please be careful when making public security claims like this.

Your VPN connection is still authenticating and validating the server using TLS and the Certificate Authority (CA) certificate you're using. A stranger isn't going to be able pretend to be your OpenVPN server. What the above commands are designed to do is protect against a very specific situation which I'll try to summarise below:

Imagine you have one VPN server, a VPN client called User A, and another VPN client called User B. They all have their own unique certificate, and the clients are validating that the server has a valid certificate using a CA file. A malicious external hacker could try to attempt to Man-in-the-Middle (MITM) your VPN connection by intercepting traffic and pretending to be the VPN server, and it would fail, as the clients would see that the malicious server's certificate is invalid and reject the connection.

So while it sounds like the setup is secure there is an edge case: imagine an attacker gets their hands on User B's certificate and key somehow and they're in a position to attempt a MITM attack against User A. User A's VPN client would see that the malicious VPN server is using a valid certificate (User B's certificate) and allow the VPN connection to connect.

To protect against such a senario, when generating the certificates for your OpenVPN server and clients you can mark them as being for "server" or "client" use. When used in combination with the "remote-cert-tls server" command, this ensures that in the above scenario User A will reject User B's certificate being used as the server's certificate.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Tue Nov 16, 2021 4:58 pm
With the serious stuff out of the way, I also want to follow up with another post just addressing your particular connection's security itself and help try to allay some fears. We've all been in a position of panic where we've gone "Have I been insecure this whole time!?", but I think in this instance you're very likely safe.

As discussed in the above post, your connection is still validating the server, and all traffic is still being encrypted. No one could listen in on your VPN network traffic, and no external attacker could MITM your connection without stolen credentials.

If this is a private OpenVPN server that you've setup and you're the only client, then you should be fine with no server-only requirement on the OpenVPN server's certificate. Other OpenVPN client certificates being used against to MITM your connection isn't something you need to worry about in such a situation. Likewise, if this is a private server with multiple client certificates, and you control all other client certificates, then you also don't need to worry about possible MITM attacks.

If this is a workplace VPN server with multiple staff, you're a slightly more risk of a MITM attack: really it comes down to whether any of those staff had their VPN credentials stolen, or whether they might act maliciously themselves.

Even if an attacker has another client's certificate, the ability to launch a MITM attack is very low. The attacker has to be in a position to intercept or divert your VPN client traffic to their malicious server, and then relay another connection to the real VPN server, which is not easy to pull off. In most instances they would need a decent level of control over the network you're connected to or the network between you and the VPN server. You would need to be up against a very sophisticated attacker who is able to both steal VPN credentials and launch a MITM attack.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
3 posts Page 1 of 1