LINUX.ORG.RU
ФорумAdmin

Расспределение ключей OpenVPN


0

0

Доброго времени суток!

Существующая инфрастуктура:

Имеется OpenVPN сервер - единственный вход в корпоративную сеть. Имеется более 80 заказчиков, на расстоянии от OpenVPN сервера от 100км до 5000км.

Задача: Как организовать механизм безопасного расспределения ключей? Ведь первоначально заказчику для установления связи с OpenVPN сервером приходится пересылать следующие данные:

ca ca.crt - публичный ключ УЦ key user.key - Секретный клю пользователя (защищён паролем) cert user.crt - Публичный ключ пользователя (сейчас пересылаю в архиве с паролем)

И самое страшное если атакующему удастся подобрать пароль к user.key Тем самым теряется всё преимущество от PKI. (я как будто пересылаю ключ симетричного шифрования просто запароленый) Или может в OpenVPN уже придумано как распределять ключи, наиболее безопасным способом, между сервером и клиентами?

Заранее спасибо за ответы!

Секретный ключ не надо пересылать вообще.

Клиент должен сгенерить секретный ключ и CSR у себя и отправить CSR админу, который его подпишет и отправит обратно user.crt и ca.crt.

INFOMAN ★★★★★
()

На клиенте:
openssl req -days 3650 -nodes -new -keyout client0.key -out client0.csr
Подписываете ключ на сервере:
openssl ca -days 3650 -out client0.crt -in client0.csr

markevichus ★★★
()
Ответ на: комментарий от markevichus

Хорошая мысль, спасибо! И как я понимю, взаимная аутентификация сервера и клента сохранится. По тому что серверный сертифика и клиентский сертификат, подписаны секретным ключом удостверяющего центра.

Кстати, если корневой сертификат самоподписаный, то возможен man-in the-middle, а если подписан третьей стороной (нпример VeriSign) то атака посредника провалится?

keferoff
() автор топика
Ответ на: комментарий от keferoff

>Кстати, если корневой сертификат самоподписаный, то возможен man-in the-middle, а если подписан третьей стороной (нпример VeriSign) то атака посредника провалится?

нет

dimon555 ★★★★★
()
Ответ на: комментарий от dimon555

Локонично однако :) Почему же нет, ведь атакующий может подминить открытые ключи при обмене, а подлинность их и не проверишь т.к. нет публичного ключа удостоверяющего центра, который кстати говоря должен был подписать открытые ключи клиента и сервера собственным секретным ключом. Так что мне кажется что вы неправы...

keferoff
() автор топика
Ответ на: комментарий от keferoff

"Локонично" - это от локона или локомотива?

По сути: М-и-М атака и СА, подписавший сертификат - ортогональны. Важно то, чьей подписи доверяет клиент. Будет доверять только "большим" СА из начального списка - тогда любой самоподписанный серт пойдет лесом. Для того, чтоб клиент молча доверял еще каким-то СА - нужны доп. технические меры, заметные (или не заметные, в виндах это возможно!) пользователю. А иначе будут громкая ругань.

svu ★★★★★
()
Ответ на: комментарий от svu

Вы вообще поняли очём речь?

1. Атакующий "помещает себя" между сервером и клиентом (ARP перенаправление например)

2. Подменяет открытые ключи сервера и клиента при передаче их от одного к другому.

3. Подменяет ca.crt при передаче от сервера к клиенту (если сa.crt самоподписанный)

4. Трафик от клиента идёт на ложный сервер атакующего, при этом (уж как реализует атакующий) трафик маршрутизируется на легитимный сервер (маршрутизируется хостом атакующего). При этом лигитимный сервер думает что трафик идёт от легитимного клиента, т.к. атакующей подминил публичные ключи и ca.crt (внимание!) при первом установлении связи (возможно вас это смутило).

А третья сторона препятствует этой атаке тем, что ca.crt (публичный ключ УЦ) уже находится в хранилище (при инсталяции ОС) и если атакующий подменит публичные ключи, тогда сервер и клиент всегда могут проверит ЭЦП на публичных ключах, заведомо правильным публичным ключом УЦ, тоесть ca.crt.

За это всяким центрам сертификации деньги и платят. Всё выше сказанное мо ИМХО т.к. чётко понимания пока к сожаленю нет...

keferoff
() автор топика
Ответ на: комментарий от keferoff

>Кстати, если корневой сертификат самоподписаный, то возможен man-in the-middle, а если подписан третьей стороной (нпример VeriSign) то атака посредника провалится?

Да.
Забей.

markevichus ★★★
()
Ответ на: комментарий от markevichus

Спасибо! Хоть один дельный ответ :) Каждый пост - проблематика для исследования, каждый комент - куча информации. Люблю ЛОР! :)

keferoff
() автор топика
Ответ на: комментарий от keferoff

можно диктовать ca.crt и сертификат по телефону. Это совсем не сложно. И нужно всего-то один раз. Ну или доставить на дискете в бронированном автомобиле с эскортом.

Bers666 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.