Suggested Improvements to Failover Support

Business solution to host your own OpenVPN server with web management interface and bundled clients.
Post Reply
chilinux
OpenVPN Power User
Posts: 156
Joined: Thu Mar 28, 2013 8:31 am

Suggested Improvements to Failover Support

Post by chilinux » Tue Nov 28, 2017 7:12 am

There are a number of areas I feel could use some improvement with the OpenVPN AS failover via ucarp.

(1) Fix User Interface error / Make page more explicit

The Failover Setting page indicates that providing the SSH password is optional and the Help page indicates public/private key authentication can be used. But at no point does it indicate what shell user account must have access to the SSH private key. It only speaks of the nodes being able to connect to each other and supplies the SSH Username with "root" already filled in for both nodes. Based on this UI layout, it could easily be taken to imply that root is not just the account being SSH into but would also be the local account which will run the SSH client. Such an assumption results in public/private key failing even when root@primary to root@secondary and root@secondary to root@primary access has been confirmed to work. The resulting error message also gives no indication of what the source local shell account user running the SSH client is. Instead, under the "Validation" section of the page, it should clearly state what shell account userid will be performing the execution of the SSH client. Ultimately, this UI flaw probably has encouraged some OpenVPN AS users to fall back to supplying a root password instead of performing public/private key authentication. This also discourages the users from periodically changing their root password as they then need to modify the failover configuration each time as well.

(2) sagent should perform Failover configuration push instead / Harden access to neighbor system's root account

It seems odd that access to the sqlite configuration files are restricted to only root/sagent access directly but the openvpn_as user can perform a ConfigQuery against the failover host root password and the ucarp secret. While it makes sense for openvpn_as user to have rights to ConfigPut and ConfigDel these keys, it would preferable if it wasn't able to pull the neighbor system's root password. If the Failover push was performed directly by sagent then there would be no need to ever expose those critical key values to openvpn_as queries. Also, it would help address the previous issue as SSH public/private key authentication from sagent would involve going from root to root instead of having the trust relationship that the unprivileged openvpn_as account is able to easily gain root access on it's neighbor system.

(3) Harden ucarp configuration and code

OpenVPN AS appears to configure ucarp with a 12 character password which is able to represent about 71 bits of entropy. Once set, I don't see any indication it is ever rotated so that 71 bits of entropy must withstand third party analysis over the entire lifespace of the OpenVPN AS install. This problem is further complicated by the fact that ucarp seems to be a very stagnant project. It continues to use SHA1-HMAC to to hide the secret which made sense when the CARP protocol was first written but really no longer considered a strong cryptographic hash any longer. if it is then taken under consideration that ucarp issues a packet every second thus supplying over 2.5 million SHA1-HMAC for analysis every month, it should be apparent that the security supplied the secret may benefit from some improvements.

The first improvement I would recommend is raising the number of characters to 22 such that 128 bits of entropy are represented. Next, I would recommend providing a method in which the secret can periodically be rotated. Lastly, the ucarp code should at some point be updated to leverage SHA3-256-HMAC to bring it back to a hash algorithm which is currently considered by the cryptographically strong. An option for multi-round hashing might also be worth investigating given how cheap performing SHA3-256 is on most systems today.

chilinux
OpenVPN Power User
Posts: 156
Joined: Thu Mar 28, 2013 8:31 am

Re: Suggested Improvements to Failover Support

Post by chilinux » Fri Dec 01, 2017 5:50 am

I have found some additional problems with OpenVPN AS use of ucarp that can hopefully be addressed in a future version:

(4) OpenVPN AS uses the same IP protocol number and multicast destination as VRRP. The packets produced are similar enough to possibly confuse some VRRP enabled devices if they are configured to use VRRP version 2 with group-id 94. However, while ucarp supports specifying an alternative multicast destination address, the OpenVPN AS web interface doesn't provide a method of changing it. It would be nice if the default destination wasn't identical to the one used by VRRP (it seems like 224.0.11.94 would be a more logical default for OpenVPN AS) and there should be an advanced option section in the web interface to change it.

(5) While ucarp allows specifying different virtual ID, the web interface also doesn't provide a method of changing that option either. This may cause problems when attempting to run multiple OpenVPN AS server pairs on the same VLAN.

(6) Given OpenVPN AS only supports a single stand-by failover node and there is not support for a cluster that exceeds two nodes, it seems like there should be some option for customers to choose an unicast based heartbeat/failover protocol.

Post Reply