11

The ubuntu docs on OpenVPN have this part in the instructions:

Copy the following files to the client:

  • /etc/openvpn/ca.crt
  • /etc/openvpn/easy-rsa/keys/hostname.crt
  • /etc/openvpn/easy-rsa/keys/hostname.key
  • /etc/openvpn/ta.key

Isn't it possible for a vpn scheme to only require an admin to install the client's public keys in order to give a client access, instead of requiring the sharing of sensitive certs first? Are there other VPNs that do this?

John Bachir
  • 301
  • 2
  • 5

3 Answers3

12

Let's look at a breakdown of all the files, whether they're sensitive, and where they came from.

/etc/openvpn/ca.crt

Publicly disposable, this is the certificate for your VPN's certificate authority. It can be shared with anybody and allows the client to verify the VPN server.

/etc/openvpn/easy-rsa/keys/hostname.crt

This is a certificate identifying the client. It was signed by the client's private key and then that was signed by the CA's key.

/etc/openvpn/easy-rsa/keys/hostname.key

This is the client's private key. In the documentation you're looking at, it was generated on the server for convenience so that the client certificate could be signed by the key there and then signed by the CA key. The private key could be generated and kept on the client without the server ever seeing it, but that would make the process a lot more complex. If you're interested, do some Googling or open another question creating a private CA -- it's a whole other department.

/etc/openvpn/ta.key

This one is a bit special, so I'll just paste some related I found at http://openvpn.net/index.php/open-source/documentation/howto.html:

tls-auth

The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

  • DoS attacks or port flooding on the OpenVPN UDP port.
  • Port scanning to determine which server UDP ports are in a listening state.
  • Buffer overflow vulnerabilities in the SSL/TLS implementation.
  • SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:

openvpn --genkey --secret ta.key

Summary

Yes, it is possible to share everything necessary in the clear except for ta.key if you generate the client's key locally and have a good method of verifying that you used the right keys. The system can be secure without ta.key -- it's just an extra measure to limit outsiders. That said, it's a really good measure.

Jeff Ferland
  • 38,170
  • 9
  • 94
  • 172
  • 1
    Wait, wait, "share everything in the clear" - even the client's private key? Most OpenVPN setups I've seen generated the client key on the server, and then passed it to the client through a secure channel (offline, usually). Or am I misunderstanding, and by "generate client's key locally" you mean "locally on the client machine"? – Piskvor left the building Mar 02 '12 at 21:33
  • 2
    @Piskvor Yes, I mean generating the client key on the client machine is possible and then having the client certificate signed on the server without transmitting the client's private key anywhere. This, for example, is common with setting up SSL on Puppet. The client key and cert are generated on the client and then the key hash is verified on the server for signing. – Jeff Ferland Mar 02 '12 at 21:41
  • Aha. Glad that's sorted out, thanks for the clarification :) – Piskvor left the building Mar 02 '12 at 21:45
  • The problem is that cleartext first exchange shouldn't be intercepted, else one does not know it actually is that client, or that server. – ewanm89 Mar 02 '12 at 22:58
  • @ewanm89 Remember that authentication and encryption are different things. We do not need them to be secret and we're ok if they're intercepted. What we need is reliable authentication -- whether that be signed by another trusted key or walking down the hall with a slip of paper that has the key's fingerprint on it. – Jeff Ferland Mar 03 '12 at 06:05
  • Yes, we use encryption in the signing to provide the authentication in one method, turns out a first connect to a server without pre-sharing a key somewhere can not be secure on it's own, how many people do you know actually check their ssh host keys with the server admin on first connect? I never said encryption and authentication are the same, I just said that first exchange needs to be authenticated that it hasn't been fiddled with in some way. – ewanm89 Mar 27 '12 at 22:37
3

To put it simply: The public key (hostname.crt) is derived, mathematically, from the private key, and it's used to verify that the client actually posesses the correct private key (and is able to decrypt it in case it's protected).

So, you absolutely need to get the private key to the client in a secure way - without this, the public key on the server is somewhat pointless.

As for the others: ca.crt is used by the client to verify that it's indeed connecting to the correct server (and not a MITM), and ta.key is a shared secret for both the client and the server (basically, "something you have").

This is a common problem for all VPN solutions using certificates. You could only use the shared secret (e.g. username+password when using PPTP), but this is 1) usually much less secure as the password isn't very long, and 2) doesn't protect you from MITM attacks.

Piskvor left the building
  • 1,654
  • 15
  • 14
1

Yes, it is possible to configure OpenVPN so you only need to install the client's public key and client's cert on the server, and only need to install the server's public key and the server's cert on the client.

Public keys and certificates are not sensitive. They're not confidential: they can be safely shared with the world, if for some reason you wanted to. They do not reveal the private key.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • Interesting -- so does your answer conflict with the suggested setup in the page I linked to? Does it conflict with @Jeff Ferland's answer? – John Bachir Mar 03 '12 at 18:21
  • 1
    This answer says the same thing as Jeff Ferland's answer. It's just at a higher, conceptual level. Conceptually, each end needs its own private key and at least one end needs the other end's certificate. (In some cases, each end may need the other's certificate.) – David Schwartz Mar 04 '12 at 00:36