aanandr@outlook.com
Hi - during username/password authentication
1. Does OpenVPN use something like MSCHAPv2?
2. The passwords would be encrypted by virtue of TLS but once they come out of the tunnel they would be in clear text. When deployed as a cloud service this allows cloud admin the possibility of looking at the password. Are the passwords hashed?
dazo
No, OpenVPN does not do any hashing or manipulation of the user credentials (username/password). This might sound odd, but it actually needs to be like this.
First of all, the credentials are encrypted when being sent over the wire (between openvpn client/server on the UDP/TCP port). But only if you use certificates (TLS mode).
Secondly, it needs to be like that because OpenVPN itself does not process the password, it just passes it further on to the third-party authentication script/plug-in. Those scripts/plug-ins have no knowledge of the SSL/TLS parameters exchanged over the wire (UDP/TCP port). It is the responsibility of these scripts/plug-ins to securely process and wipe the credentials when no longer needed. If OpenVPN would hash the password, the authentication script/plug-in would not be able to make too much sense out of that hash. Now, it can be possible to add some challenge/response protocols, to avoid sending the password at all over the wire - but that requires both a plug-in/management integration on the server and client side, otherwise OpenVPN will not know what to do. Again, OpenVPN just transports the authentication credentials between the end-points, it doesn't act upon it. The only situation where OpenVPN can act upon the authentication process is if the server is v2.4 or later and it is configured to use --auth-gen-token. But this still requires a successful user/password authentication to have happened first, through an authentication script/plug-in.
As a side note to --auth-gen-token, when using this feature on a v2.4 server - all OpenVPN v2.3 clients and newer will replace the cached user password with an authentication token if the initial authentication was successful. This means that the OpenVPN client will only transport the password once over the wire, on all following tunnel re-negotiations the authentication token will be used instead. This is also possible to achieve without using --auth-gen-token, but that requires an authentication script/plug-in with support for sending an auth-token value to the client (through dynamic "client-config-dir" options). If an authentication script/plug-in support this, this will also work with OpenVPN v2.3 servers.
Also note that NO username/password "exits" unto the TUN/TAP device OpenVPN is configured to use. You cannot sniff any OpenVPN client's user credentials on the TUN/TAP device at all. This is due to authentication data being passed over the control channel; the data which is being read/written to the TUN/TAP device are transported over the data channel. The control channel is only accessible to the OpenVPN processes and is used to send configuration settings, exchange client/server certificates, exchange encryption keys for the data channel, exchange client/server information - and to perform user authentication using additional credentials. Further the OpenVPN clients connected to the same OpenVPN server does not have access to other OpenVPN client's control channel. Each client have a separate control channel, which the server is responsible to manage.
Lastly, there are a few scenarios where the control channel is unencrypted, that is in the very beginning where certificates and some configuration parameters are exchanged. Starting with the coming OpenVPN v2.4, a new feature will be introduced, --tls-crypt, which will encrypt most of the control-channel. This feature works similarly to how the --tls-auth feature works, which adds another safe-guard on top of the SSL/TLS protocol by using pre-shared static secrets. --tls-crypt uses the same static key format as --tls-auth. The intention is that you either use --tls-auth or --tls-crypt as the latter on is adding encryption on top of the HMAC signature --tls-auth adds.
