Does unsecure delivery of keys and certs make a VPN useless?

Question

I had to install an OpenVPN service onto a fresh, disconnected computer, but the keys and certs were delivered through an insecure computer with a highly suspect connection.

Let's assume that the TLS Auth Key, CA Cert, Public Client Cert, and Public Client Key were all intercepted during delivery--wouldn't that render the VPN connection pointless? If I must manually enter or copy-paste these keys and certs into fields during VPN installation, how should I securely obtain the keys and certs?

The VPN has the following specs:

DATA CHANNEL CIPHERS

AES-256-CBC with HMAC-SHA1 for authentication

---

CONTROL CHANNEL CIPHERS

AES-256-GCM with HMAC-SHA384 for authentication

AES-256-CBC with HMAC-SHA1 for authentication

---

4096 bit RSA keys size

4096 bit Diffie-Hellman keys size

TLS Ciphers (IANA names): TLS-DHE-RSA-WITH-AES-256-CBC-SHA, TLS-DHE-RSA-WITH-AES-256-GCM-SHA384

TLS additional authorization layer key: 2048 bit

Perfect Forward Secrecy through Diffie-Hellman key exchange DHE. After the initial key negotiation, re-keying is performed every 60 minutes (this value can be lowered unilaterally by the client)

Answer 1

I think you're using non standard terminologies and that is making things confusing for you. I'll define the terms here:

1. Private key: a string that need to be kept secret, used in cryptographic operations to authenticate or encrypt
2. Public key: a string that are mathematically bound to the private key, not a secret. Used in certificate to decrypt and identify signatures that matches a private key
3. Certificate: public key + optional associated data + signature of the CA binding the key with the associated data. Not a secret. Each side in the communication uses the associated data in the certificate to identify its peer.

TLS Auth Key, the client private key, and server private key are the only data that should be keep private by the client and server respectively.

In the normal operation of x.509 authentication, the server doesn't need to know the client's private key, and vice versa the client doesn't need to know the server's key. You only need to deliver your public keys to the CA in a way that the CA can verify that they are signing the right public key for the right entity for the right purposes.

The CA's root certificate, the server's public key and certificate, and the client's public key and certificate are all non secret. The security properties of PKI does not rely on the secrecy of public key and certificates. An attacker can intercept these and that won't help them decipher your communication with the server.

An attacker that can passively intercept your communication with the CA would not be able to intercept your communication to the server either. To intercept your communication with the server, the attacker would need to actively modify your communication with the CA, throughout the entire verification process and throughout all your communication with the server.

In short, yes, insecure delivery of certificate signing request to the CA can make PKI useless. Insecure delivery of the certificate to communication peer though, is not an issue as all the information exchanged are public.

Answer 2

It's much easier for an attacker to sniff traffic without getting caught than to intercept and modify that traffic. Sniffing traffic is easy, just set up the software and hit record. Interception and modification requires the attacker to know what type of traffic to expect and what validation steps the user is or is-not taking.

So the "correct" way to set up an openvpn client with minimal trust would be.

1. Generate a keypair and CSR on the client.
2. Send the CSR to the server admin
3. Receive the certificates back from the server admin

Of course none of this helps you if the attacker is capable of perfectly impersonating the server admin.

Risk can be further reduced by using a separate channel, for example you might speak to the server admin on the phone and confirm the public keys verbally.

The TLS auth key seems to be an extra "defense in depth" measure rather than a key part of the VPNs security.

Answer 3

All the cert and keys you are presenting are necessary information for a working openvpn service for the client side.

It is nothing wrong to give them in public. The only security weakness is the username:password (if it is weak) and your IP (ddos attacks).