Как безопасно передать openvpn ключи от сервера клиенту, что будет если ключи словят?

Question

[Сергей]

По всем мануалам, что я смог нагуглить, ключи генерируются на сервере, что для клиента, что для сервера. Затем передаются.
И тут встает ряд вопросов, т.к. я малокомпетентен:

1. Как безопасно передать ключи клиенту? Ведь в случае митм их сразу же перехватят, да и без этого провайдер хранит логи, фильтрует трафик, может по критериям каким ловит и ключи эти, кто знает, что за нанотехнологии применяют, в общем, как безопасно можно их передать? В запароленном архиве, мне кажется, не очень надежно. еще варианты?

2. Если, предположим, ключи поймали, то они смогут трафик собрать и расшифровать, верно? Ведь в этом случае, обменявшись ключами с сервером, смогут узнать ключ, которым шифруют (в случае с диффи-хэлманом). Или ключи нужны только для подключения, мол схватив ключи смогут подключиться, но не смогут прослушать трафик и он будет зашифрован?

Answer 1

[ComodoHacker]

Полагаю, среди всех нагугленных мануалов вы не обошли вниманием и официальный, а именно раздел про генерацию сертификатов: https://openvpn.net/index.php/open-source/document... В конце этого раздела есть ответ на ваш первый вопрос.

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.

Как верно заметил res2001, для исключения перехвата по незащищенному каналу нужно передавать не приватный ключ, а запрос на сертификат. В скриптах build-key и build-key-server, входящих в поставку OpenVPN и используемых в примерах, шаги по генерации пары ключей, генерации запроса к CA и подписи сертификата объединены, но их можно разделить. Загляните внутрь скриптов и поймете.

Что касается второго вопроса. Если в руки злоумышленника попадет клиентский сертификат с приватным ключом, то он сможет подключиться к серверу от имени клиента. Ключ для шифрования трафика генерируется свой для каждой сессии. Вашу сессию злоумышленник сможет прослушать, если перехватит ваш трафик в момент подключения и применит MitM атаку.

Это все отностися к работе в режиме PKI. Есть еще режим работы со статическим ключом (описан здесь: https://openvpn.net/index.php/open-source/document..., там ключ один единственный и общий, передавай как хочешь. А если ключ утек - считай все пропало, можно расшифровывать любые сессии, в том числе записанные ранее.

Comments

[res2001]

ComodoHacker "Вашу сессию злоумышленник сможет прослушать, если перехватит ваш трафик в момент подключения и применит MitM атаку." - думаю это не верно, т.к. сессионные ключи при передаче должны шифроваться на ключах PKI, поэтому перехват момента соединения ни к чему не приведет - трафик все равно будет зашифрован.

[ComodoHacker]

Тонкостей генерации и передачи сессионных ключей в OpenSSL я не знаю. Но имея клиентский сертификат с приватным ключом, злоумышленник однозначно может установить соединение с сервером, пройти аутентификацию и инициализировать сессию. А вот сможет ли он установить соединение с клиентом, прикинувшись сервером, зависит от того, включена ли на клиенте проверка сертификата сервера. Многие не настраивают это.
https://openvpn.net/index.php/open-source/document...

Answer 2

[Армянское Радио]

Через ssh ключи передайте и все.

Answer 3

[res2001]

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

Answer 4

[xmoonlight]

1. Регистрация пользователя на сайте (двухфакторная, SSL/TLS) - по клику из почты сохраняем токен на клиенте.
2. После захода пользователя по токену и попытке скачать сертификат - шифруем файл на сервере с помощью токена и парольного хеша.
3. На клиенте расшифровываем токеном и парольным хешем, который формируем после того, как пользователь введёт пароль.

Таким образом, двухфакторная регистрация (сайт+почта, всё через SSL/TLS) и никогда не пересылаемый клиентский токен, позволяют максимально обезопасить сертификат от MiTM-атаки.