Re: Выбор метода шифрования для OpenVPN
At Wed, 11 Mar 2009 11:23:36 -0400,
Nicholas wrote:
> > Не производный, а случайный ключ, который генерируется прямо во время
> > сеанса. Асимметричное шифрование излишне ресурсоёмкое, поэтому данные
> > сеанса им не шифруются. Им шифруется только стадия обмена сеансовым
> > ключом симметричного шифрования. Дальнейшее шифрование сеанса
> > происходит без участия ключей ассиметричного шифрования.
>
> Я так понял, что при коннекте клиента к openvpn, с использованием x.509
> происходит:
>
> 1. "Использование" "tls-auth ta.key" для "для предотвращения DoS-атак и
> UDP port flooding", который хранится и на сервере и у клиента. (как
> используется ? Алгоритм пока непонятен.)
> 2. Авторизация по x.509 ( ключи х.509 никак не используются для шифрации
> трафика). Клиент проверяет, что его сертификат и серт клиента подписанны
> одним СА, и то что сертификата клиента нет в списке отозванных (при
> опции --crl-verify).
> 3. Пересылка клиенту производного от закрытого dh dh2048.pem (который,
> в отличие от ta.key хранится только на сервере) открытого ключа который
> используется для ассимитричного(!) шифрования, для пересылки сессионного
> ключа.
> 4. Генерация произвольного сессионного симметричного ключа сервером
> (видимо сервером, ведь клиент не обязан иметь библиотеку openssl ?)
Обязан.
> и пересылка его клиенту.
>
> Это правильное понимание ?
Нет.
Точнее скажет Витус, он туда лазил. Но насколько я понимаю, общий принцип -
клиент и сервер взаимно авторизуются в процессе установления TLS-соединения, а
уже по установленному шифрованному каналу договариваются о собственно рабочем
ключе, равно как и о параметрах туннеля (адресах, роутинге и пр.).
Далее. Как именно в OpenVPN используется DH, я тоже сходу не скажу, но он в
принципе не используется для шифрования. Не может. Он используется для
выработки общего ключа обеими сторонами без собственно пересылки оного ключа.
В принципе, потом этот общий ключ можно использовать для пересылки "рабочего"
ключа (так происходит в S/MIME, если пользоваться алгоритмами ГОСТ - там как
раз подобная схема), а можно - для раздельной выработки рабочих ключей на
обеих сторонах (так происходит в TLS). Насколько я себе представляю, вариант
с пересылкой рабочего ключа с "честным" DH нигде не используется. В S/MIME с
ГОСТ он используется из тех соображений, что прямого аналога RSA у нас нет, а
существующие приложения по-другому просто не умеют. Поэтому приходится
мудрить с эфемерным ключом и шифрованием рабочего ключа на парном.
> > OpenVPN пользуется именно библиотекой OpenSSL. Я думаю документацию
> > нужно рыть там.
>
> Кто-нибудь может посоветовать краткую, но глубокую доку (rus/eng) из
> серии "как это работает" (а не "что надо сделать, чтобы заработало") ?
Для начала надо брать описание протокола OpenVPN. Это нестандартная хрень,
поэтому искать надо в его доке. Там, где он будет отсылать к TLS - брать RFC
на TLS :-) Ну, дальше по вкусу, вплоть до "Прикладной криптографии".
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Reply to: