Suggested Improvements to Failover Support
Posted: 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.
(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.