id: Гость   вход   регистрация
текущее время 02:18 29/03/2024
создать
просмотр
ссылки

OpenVPN сервисы и clien.key


Здравствуйте!
Подскажите пожалуйста насколько безопасны покупные OpenVPN сервисы. Просто обратил внимание на то, что файлы: ca.crt, client.crt и clien.key передаются всем клиентам одинаковые. Разница только в паролях самих клиентов, которые проверяются при подключении к серверу.
Как известно файл clien.key является секретным файлом.


Подскажите пожалуйста сможет ли противник расшифровать (частично расшифровать) трафик если он знает секретны ключ клиента (clien.key) и несекретные ca.crt, client.crt? Сможет ли противник произвести атаку Man in the middle ?
Всем откликнувшимся заранее огромное спасибо!


 
Комментарии
— Гость (06/08/2013 11:23)   <#>
а каким способом вам передается секретный ключ? да и сертификаты?
— unknown (06/08/2013 11:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Разница только в паролях самих клиентов, которые проверяются при подключении к серверу.

В любом случае — это какая-то неполноценная конфигурация, которая вполне может выполнять то, чего вы опасаетесь. Клиентские файлы и сертификаты должны быть уникальными, а пароль должен использовать только для их шифрования, или для совместного использования. Точно всех опций OpenVPN сейчас не вспомню, но с такими настройками не сталкивался, скорее всего они означают экономию на безопасности.
— Гость (06/08/2013 12:02)   <#>

MITM, скорей всего, сделать сможет, но с этим надо разбираться. Вообще, в настройках коммерческих сервисов может быть всё, что угодно.* С SSH недавно эту ситуацию разбирали, с OpenVPN — нет. В любом случае, наличие какого-либо пароля для OpenVPN — плохо и бред. При нормальной настройке клиент всегда аутентифицируется только с помощью сертификата (как и в SSH).

*Включая отсутствие DH(?), как это недавно стало широко известным про SSL (или DH в OpenVPN всегда?).
— Гость (06/08/2013 12:15)   <#>
В любом случае, наличие какого-либо пароля для OpenVPN — плохо и бред
Логин и пароль не исключается при использовании сертификатов и секретного ключа пользователя.
— unknown (06/08/2013 12:34)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В OpenVPN может вообще использоваться симметричный предрасшаренный ключ без асимметрики. Не знаю, возможно ли при этом параллельно использование сертификатов и/или паролей только для аутентификации, но без выработки сеансового ключа по DH/RSA.
— Гость (06/08/2013 13:22)   <#>

Да, был не прав, всё оказывается чуть тоньше, особенно если немного подумать не только о криптографии, но и анонимности. Вот чуть более развёрнуто:

Включен ли DH — зависит от конфигов сервера. OpenVPN можно вообще завести со статическим симмитричным ключом. Возможность MITM при одинаковом client.key зависит от конфига клиента и правильности генерации сертификатов сервера. Если в конфиге клиента прописано ns-cert-type server (синоним — remote-cert-tls server), и в сертификате сервера есть соответствующее поле (а в сертификатах клиента, соответственно, нет этого поля, поскольку оно означает, что сертификат серверный**), то MITM невозможен. Если сертификаты сгенерены неправильно, то можно вместо серверного сертификата подсунуть клиентский.

С точки зрения анонимности более правильная конфигурация — без клиентских сертификатов, где сервер аутентифицируется по сертификату, используется DH, а клиент аутентифицируется по паролю. Суть в том, что тогда в видимом третьей стороной трафике отсутствуют различители, т.е. процесс коннекта всех клиентов выглядит одинаково без возможности отличить одного от другого, если же используются клиентские сертификаты, третья сторона может различать клиентов. Различение клиентов возможно, потому что обмен сертификатами идет в открытом виде, а шифрованный канал устанавливается только после. Будут у клиентов разные сертификаты — третья сторона может различать клиентов, при парольной же авторизации пароль передается уже после установления канала.

OpenVPN очень гибкий в настройках. Аутентифицировать клиентов можно и по паролю и по сертификатам, можно наворачивать всё, что угодно. Сертификаты у всех клиентов могут быть как разные, так и одинаковые. Получается, что можно авторизовать и так, и так и эдак, и еще вот так, и даже сразу несколькими способами, можно сделать абсолютно по-разному. Например, у сервера может быть сертификат, а у клиента нет. Или у всех клиентов может быть одинаковый сертификат + авторизация по паролю. Ещё у клиента с сервером может быть общий симмитричный ключ (+ авторизация по паролю или без нее). И поверх всего этого может как быть DH, так и не быть, — зависит от того, как настраивать и какой логикой пользоваться.

Помимо всего этого в OpenVPN есть ta-key — это общий для сервера и всех клиентов симмитричный ключ, использующийся для дополнительной авторизации канала на стадии установки соединения. Он нужен для того, чтобы снизить площадь атаки при наличии каких-либо уязвимостей. Опять же, он может быть, а может и не быть (всё определяется настройками). Впрочем, если он есть, то третья сторона всё равно сможет различать клиентов, которые используют только сертификаты, потому что он не шифрует, а только авторизует. Тем не менее, третья сторона, не имеющая этого ключа, не сможет воспользоваться уязвимостью в OpenVPN, в этом его смысл. А так, чтоб шифровалось и согласование ключей, ничего нет.

И ещё раз: DH можно использовать или не использовать независимо от каких бы то ни было методов аутентификации (можно вообще сделать аутентификацию по shared key + DH). Для анонимности можно порекомендовать такую конфигурацию: сервер использует ta-key, DH и RSA-сертификат, а клиенты не имеют сертификатов и авторизуются по паролю. В общем, общий сертификат для всех клиентов может быть, хуже от него вроде не станет.

Поскольку DH не может быть сделан без кооперации с клиентом, его наличие можно узнать по логам соединения, где будет писаться что-то типа
Control Channel: XXX, cipher XXX/XXX DHE-XXX-XXX-XXX, XXX bit XXX
Упоминание DHE — вот это оно. По логам можно узнать и другую (хоть и частичную) информацию о конфигурации сервера.


Возможно.

P.S. Не забывайте, что надёжная криптография и анонимность могут выдвигать прямо противоположные требования к настройкам.

**Если оно есть в сертификате клиента, можно взять этот сертификат и выдать за серверный, сделав MITM.
— Гость (06/08/2013 14:15)   <#>

Points:
  • Если импользуется DH, расшифровать не cможет.
  • MITM возможен только в случае неправильной конфигурации.
— filipp_85 (06/08/2013 23:34)   профиль/связь   <#>
комментариев: 3   документов: 4   редакций: 0
Всем ответившим СПАСИБО !!!
DH используется:
" Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA"
От MITM они в клиенском конфиге прописывают "remote-cert-tls server"

Но все равно, как смущало, что секретны ключ клиента (clien.key) общедоступен, так и смущает......
— Гость (07/08/2013 01:00)   <#>

Его могло бы вообще не быть. Это не смущало бы? :)
— Гость (29/01/2014 16:06)   <#>
некоторые сервисы предлагают использование 4096 битных ключей, где-то читал, что это маркетинговый ход, а возможно ли, что при подключении используется 1024, например, вместо указанного в логах 4096?
— Гость (29/01/2014 22:35)   <#>

Смысла большого не вижу. Снизить нагрузку? Так там новые сессии не так часто генерятся, асимметрика только для выработки симметричного ключа вроде как используется. Если параноить по поводу злонамеренности оператора VPN, то вывод будет тот же: нет смысла. Уж если он злонамерен, он и так может сливать весь ваш трафик куда хочет и когда хочет, и вы этого не заметите, как бы ключи ни были, потому что трафик на его стороне полностью расшифровывается.
— Гость (29/01/2014 22:36)   <#>
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3