How to safely transfer openvpn keys from the server to the client, what will happen if the keys are caught?

Question

openvpn

According to all the manuals that I could google, the keys are generated on the server, both for the client and for the server. Then they are transferred.
And here a number of questions arise, because. I'm incompetent:
1. How to safely transfer the keys to the client? Indeed, in the event of a mitm, they will be immediately intercepted, and even without this, the provider stores logs, filters traffic, can catch these keys according to the criteria, who knows what kind of nanotechnologies are used, in general, how can they be safely transferred? In a password-protected archive, it seems to me, not very reliable. more options?
2. If, suppose, the keys are caught, then they will be able to collect and decrypt traffic, right? Indeed, in this case, having exchanged keys with the server, they will be able to find out the key with which they encrypt (in the case of diff-healman). Or are the keys needed only to connect, saying that by grabbing the keys they will be able to connect, but they will not be able to listen to the traffic and it will be encrypted?

Answer 1

I believe that among all the manuals you googled, you did not ignore the official one, namely the section on generating certificates: https://openvpn.net/index.php/open-source/document... At the end of this section there is an answer to your first question .

The final step in the key generation process is to copy all files to the machines which need them, taking care to copy secret files over a secure channel.
Now wait, you may say. Shouldn't it be possible to set up the PKI without a pre-existing secure channel ?
The answer is ostensibly yes. In the example above, for the sake of brevity, we generated all private keys in the same place. With a bit more effort, we could have done this differently. For example, instead of generating the client certificate and keys on the server, we could have had the client generate its own private key locally, and then submit a Certificate Signing Request (CSR) to the key-signing machine. In turn, the key-signing machine could have processed the CSR and returned a signed certificate to the client. This could have been done without ever requiring that a secret .key file leave the hard drive of the machine on which it was generated .

As res2001 rightly noted , in order to exclude interception over an insecure channel, it is necessary to transmit not a private key, but a certificate request. In the build-key and build-key-server provided with OpenVPN and used in the examples combine the steps for generating a key pair, generating a CA request, and signing a certificate, but they can be separated. Look inside the scripts and you will understand.
As for the second question. If a client certificate with a private key falls into the hands of an attacker, he will be able to connect to the server on behalf of the client. The key for encrypting traffic is generated for each session. An attacker will be able to listen to your session if he intercepts your traffic at the time of connection and applies a MitM attack.
This is all related to working in PKI mode. There is also a mode of working with a static key (described here: https://openvpn.net/index.php/open-source/document... , there is only one and common key, pass it as you like. And if the key is leaked, count everything lost, you can decrypt any session, including those recorded earlier.

Answer 2

Pass the keys through ssh and that's it.

Answer 3

Правильно как раз ключи генерировать на клиенте, в центр сертификации передается запрос на сертификат, ЦС возвращает сертификат, клиент передает сертификат на сервер. ЦС и сервер в общем случае это разные сущности, и, если по взрослому, это даже разные организации.

Answer 4

1. User registration on the site (two-factor, SSL / TLS) - by clicking from the mail, we save the token on the client.
2. After the user logs in using the token and tries to download the certificate, we encrypt the file on the server using the token and the password hash.
3. On the client, decrypt with a token and a password hash, which is generated after the user enters the password.
Thus, two-factor registration (website + mail, all via SSL / TLS) and a never forwarded client token allow you to maximize the security of the certificate from MiTM attacks.