by
forest » Sat Mar 31, 2018 11:04 am
virtualmike wrote:Code: Select all
WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
I grabbed the latest client.ovpn from ovpn.sonic.net, and it has the same ns-cert-type setting. Should I be concerned about this?
IIRC, Sonic's openvpn config directs the client to trust the server if the server's certificate was signed by Sonic's certificate authority. This is a good thing, because it helps prevent a random person from mounting a man-in-the-middle attack, impersonating Sonic's server and intercepting your communications. It's not quite enough, though: Every client config issued by Sonic contains its own certificate that is also signed by that same CA, and is therefore trusted by every other client config. This means that, without an additional check of some kind, literally anybody who can sign up for Sonic service or get their hands on a Sonic customer's password or openvpn config, could impersonate the server.
To prevent this, we need our VPN clients to distinguish between the server's cert and a customer's cert, and reject the latter. The "ns-cert-type server" directive is doing that job. Removing it without first putting something else in place to do that job would be unwise.
The "remote-cert-tls server" directive could take over that job, but it would require Sonic to generate a new server certificate containing the corresponding "key usage" flag. (I believe this could be done without breaking existing clients. It had not yet been done when I checked last year.)
Of course, since the directive currently in use is deprecated, there is a risk that a future openvpn version might drop support for it before Sonic adds the new flag to their cert, leaving us either with broken VPN configs or (if we were to remove the deprecated directive) exposed to MITM attacks. If that should happen, I would suggest replacing the directive with some other one that will reject a client cert if it were ever used to impersonate the server. For example:
Code: Select all
verify-x509-name 'CN=OpenVPN Server'
That might seem a bit hackish, but it would work as long as Sonic never allows a customer to choose a username of "OpenVPN Server".