OpenVPN сервисы и clien.key
Здравствуйте!
Подскажите пожалуйста насколько безопасны покупные OpenVPN сервисы. Просто обратил внимание на то, что файлы: ca.crt, client.crt и clien.key передаются всем клиентам одинаковые. Разница только в паролях самих клиентов, которые проверяются при подключении к серверу.
Как известно файл clien.key является секретным файлом.
Подскажите пожалуйста сможет ли противник расшифровать (частично расшифровать) трафик если он знает секретны ключ клиента (clien.key) и несекретные ca.crt, client.crt? Сможет ли противник произвести атаку Man in the middle ?
Всем откликнувшимся заранее огромное спасибо!
комментариев: 9796 документов: 488 редакций: 5664
В любом случае — это какая-то неполноценная конфигурация, которая вполне может выполнять то, чего вы опасаетесь. Клиентские файлы и сертификаты должны быть уникальными, а пароль должен использовать только для их шифрования, или для совместного использования. Точно всех опций OpenVPN сейчас не вспомню, но с такими настройками не сталкивался, скорее всего они означают экономию на безопасности.
MITM, скорей всего, сделать сможет, но с этим надо разбираться. Вообще, в настройках коммерческих сервисов может быть всё, что угодно.* С SSH недавно эту ситуацию разбирали, с OpenVPN — нет. В любом случае, наличие какого-либо пароля для OpenVPN — плохо и бред. При нормальной настройке клиент всегда аутентифицируется только с помощью сертификата (как и в SSH).
*Включая отсутствие DH(?), как это недавно стало широко известным про SSL (или DH в OpenVPN всегда?).
комментариев: 9796 документов: 488 редакций: 5664
Да, был не прав, всё оказывается чуть тоньше, особенно если немного подумать не только о криптографии, но и анонимности. Вот чуть более развёрнуто:
Включен ли 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 не может быть сделан без кооперации с клиентом, его наличие можно узнать по логам соединения, где будет писаться что-то типа
Возможно.
P.S. Не забывайте, что надёжная криптография и анонимность могут выдвигать прямо противоположные требования к настройкам.
**Если оно есть в сертификате клиента, можно взять этот сертификат и выдать за серверный, сделав MITM.
Points:
комментариев: 3 документов: 4 редакций: 0
DH используется:
" Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA"
От MITM они в клиенском конфиге прописывают "remote-cert-tls server"
Но все равно, как смущало, что секретны ключ клиента (clien.key) общедоступен, так и смущает......
Его могло бы вообще не быть. Это не смущало бы? :)
Смысла большого не вижу. Снизить нагрузку? Так там новые сессии не так часто генерятся, асимметрика только для выработки симметричного ключа вроде как используется. Если параноить по поводу злонамеренности оператора VPN, то вывод будет тот же: нет смысла. Уж если он злонамерен, он и так может сливать весь ваш трафик куда хочет и когда хочет, и вы этого не заметите, как бы ключи ни были, потому что трафик на его стороне полностью расшифровывается.
каккакими бы ключи ни были