Comments 9
Одной из причин перехода с OpenVPN на WireGuard стала улучшенная безопасность в WireGuard.Я не большой фанат OpenVPN, но ситуация скорее обратная.
- OpenVPN проходил аудит безопасности, а Wireguard нет.
- OpenVPN поддерживает множество шифров и не является заложником какого-то одного в случае, если в нём будут найдены фатальные проблемы. Wireguard в текущий момент времени поддерживает ровно один комплект криптопримитивов.
- Wireguard полагается на статические ключи, которые должны быть предварительно распространены и сконфигурированы на узлах, а значит требует какого-то внешнего решения для закрытия этой проблемы, которое так же нуждается в аудите. OpenVPN может полагаться на стандартную PKI.
Приведённое Вами утверждение ничем не подкреплено. Кроме этого, по информации с официального сайта ни одного стабильного релиза так и не было:
WireGuard is currently working toward a stable 1.0 release. Current snapshots are generally versioned «0.0.YYYYMMDD» or «0.0.V», but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software). This text will be removed after a thorough audit.То есть авторы не пока не рассматривают его как production ready.
WireGuard задействует крипто-версионирование для предупреждения крипто-атак.Мне попадалось это утверждение в статьях о Wireguard, но в самой спецификации нет вообще ничего про версию. Надо понимать, что это такая обтекаемая форма утверждения «в случае чего просто поменяем всё под корень».
Говоря о производительности самого Wireguard, следует заметить что рекордные скорости он достигает благодаря размещению модулем прямо в ядре Linux. На всех остальных платформах, где Wireguard реализован в юзерспейсе, скорость будет сопоставимая с OpenVPN и будет проигрывать решениям, которые реализованы драйвером в ядре (например, IKEv2 IPsec).
В новейшей версии решения Veeam PN мы перешли от использования OpenVPN к WireGuard, поскольку именно WireGuard постепенно становится новым стандартом в индустрии VPN-технологий.Wireguard модный, перспективный, но пока он не конкурент даже IPsec по причине неполного соответствия функционалу обычных VPN-серверов и отсутствия зрелости.
Я не большой фанат OpenVPN, но ситуация скорее обратная.
OpenVPN проходил аудит безопасности, а Wireguard нет.
Вообще, проводилось множество исследований криптостойкости WireGuard, как конкретной реализации, так и самого протокола. Навскидку, вот и вот. К тому же, аудит 4000 строк кода не в пример легче, чем аудит сотен тысяч.
Кроме того, WireGuard (по крайней мере kernel версия) использует реализацию крипто-примитивов и самого протокола, сгенерированных с использованием методов формальной верификации. Неплохо зная внутреннее устройство OpenVPN, я даже не могу представить, чтобы можно было полностью формально верифицировать или доказать криптостойкость протокола OpenVPN, хотя попытки были, например вот тут.
OpenVPN поддерживает множество шифров и не является заложником какого-то одного в случае, если в нём будут найдены фатальные проблемы. Wireguard в текущий момент времени поддерживает ровно один комплект криптопримитивов.
Множество, только абсолютное большинство из них уже устарело. Из тех шифров, которые удовлетворяют современным требованиям я бы назвал только AES-128/192/256-CBC. И то, CBC режим подвержен уязвимостям .
Поддержка современных режимов шифрования (e.g. AES-256-GCM) и perfect forward secrecy (e.g. ECDHE) появилась только в версии 2.4 и не поддерживается в более старых версиях, которых до сих пор полно на просторах сети. В общем и целом, OpenVPN гораздо проще настроить неправильно, с использованием небезопасной криптографии.
В качестве примера, в TLS 1.0-1.2 поддерживалось огромное количество crypto suites, но в TLS 1.3 выкинули абсолютное большинство из них, оставив (и несколько добавив) очень малую часть крипто наборов. Из-за этого (и из-за изменений в протоколе) клиенты TLS 1.2 не имеют возможности подключиться к TLS 1.3 only серверам. А в TLS 1.1 и 1.2 множество крипто наборов помечены как небезопасные или условно-безопасные. И тут уж зависит от конфигурации конкретных серверов/клиентов будут ли использоваться эти слабые крипто наборы. По мне так лучше вообще потерять возможность соединения, чем пользоваться небезопасной криптографией.
Wireguard полагается на статические ключи, которые должны быть предварительно распространены и сконфигурированы на узлах, а значит требует какого-то внешнего решения для закрытия этой проблемы, которое так же нуждается в аудите. OpenVPN может полагаться на стандартную PKI.
Для WireGuard тоже можно придумать реализацию PKI, благо клиенты и так аутентифицируются по публичным/приватным ключам, которые суть есть Curve25519, так что можно раздавать клиентам те же ECC SSL сертификаты. То, что поддержка PKI не зашита в протокол WireGuard по-моему только плюс. Это, конечно, может быть минусом для корпоративного сектора, но думаю и там в скором времени найдётся решение.
То есть авторы не пока не рассматривают его как production ready.
При этом о поддержкe WireGuard и предоставлении сервисов на его основе уже заявило большинство крупнейших VPN провайдеров. А Cloudflare, например, вообще свою реализацию WireGuard протокола на Rust написали.
Говоря о производительности самого Wireguard, следует заметить что рекордные скорости он достигает благодаря размещению модулем прямо в ядре Linux. На всех остальных платформах, где Wireguard реализован в юзерспейсе, скорость будет сопоставимая с OpenVPN и будет проигрывать решениям, которые реализованы драйвером в ядре (например, IKEv2 IPsec).
Насчёт сравнения с OpenVPN я бы поспорил. Реализация протокола поверх UDP в OpenVPN довольно примитивна: обычное скользящее окно фиксированного размера (на 8 пакетов если правильно помню), с возможностью подтверждения доставки сразу нескольких пакетов. Реализация сетевого взаимодействия в WireGuard тоже далека от оптимальной, но в отличие от OpenVPN, тут есть возможность использовать все доступные CPU для шифрования и обработки пакетов. OpenVPN же в версии 2.X все данные всегда обрабатывает в однопоточном режиме. Версия 3.X, в которой добавлена поддержка многопоточности, уже более 7 лет находится в состоянии разработки, ни одного релиза так до сих пор и не было.
Wireguard модный, перспективный, но пока он не конкурент даже IPsec по причине неполного соответствия функционалу обычных VPN-серверов и отсутствия зрелости.
Тут, конечно, только время покажет, но лично я голосую за WireGuard :-)
При этом о поддержкe WireGuard и предоставлении сервисов на его основе уже заявило большинство крупнейших VPN провайдеров. А Cloudflare, например, вообще свою реализацию WireGuard протокола на Rust написали.
Да, я сам использовал в прошлом AzireVPN потому, что они начали поддерживать wireguard. Однако, вот что:
- Поддержку wireguard выкатили на данный момент только, наоборот, самые мелкие провайдеры. Они в первую очередь заинтересованы в уникальном торговом предложении, а не в реальной безопасности. Поэтому AzireVPN наряду с wireguard предлагает и SOCKS5 без шифрования, а, например, vpn.ac предлагает PPTP (с MPPE на шифре RC4) и L2TP/IPsec с PSK для аутентификации сервера, который знают все клиенты. Wireguard на слуху, вот они и подсуетились. А старые протоколы поддерживают потому что и на них есть спрос со стороны владельцев старого оборудования. То есть, это из-за спроса, а не из-за безопасности.
- Вероятнее всего, CF пилил эту реализацию для своего Cloudflare Warp, который недавно запустился. Это VPN для мобильных и wireguard туда отлично вписывается потому, что прочно держит соединение, тут лучше чем wireguard и правда не придумать. Кроме того CF ещё имеет кое-какие амбиции по борьбе с цензурой, а у wireguard обфусцированный протокол.
Множество, только абсолютное большинство из них уже устарело. Из тех шифров, которые удовлетворяют современным требованиям я бы назвал только AES-128/192/256-CBC. И то, CBC режим подвержен уязвимостям.Так помимо блочного шифра транспортного канала, с которым проблем и так особо нет, в шифронабор входят вариации согласования ключей по Диффи-Хеллману, псевдослучайная функция и асимметричные ключи подписи, к которым обычно больше вопросов. Вот в вайргарде оно всё прибито гвоздями, в OpenVPN и других хотя бы пара рабочих вариантов есть. И по той причине, что в протоколе wireguard применяется обфускация точек эллиптической кривой, которая специфична для этой конкретной кривой, по-другому не будет, там можно весь шифронабор только разом сменить.
Поддержка современных режимов шифрования (e.g. AES-256-GCM) и perfect forward secrecy (e.g. ECDHE) появилась только в версии 2.4 и не поддерживается в более старых версиях, которых до сих пор полно на просторах сети. В общем и целом, OpenVPN гораздо проще настроить неправильно, с использованием небезопасной криптографии.
Для WireGuard тоже можно придумать реализацию PKI, благо клиенты и так аутентифицируются по публичным/приватным ключам, которые суть есть Curve25519, так что можно раздавать клиентам те же ECC SSL сертификаты. То, что поддержка PKI не зашита в протокол WireGuard по-моему только плюс. Это, конечно, может быть минусом для корпоративного сектора, но думаю и там в скором времени найдётся решение.Общего решения, сохраняющего свойства wireguard, не найдётся точно, потому что обнажение публичных ключей идёт вразрез с целями протокола Noise. Wireguard использует паттерн IK протокола Noise, и для получения гарантий, которые он предоставляет, инициатор должен знать публичный ключ ответчика заблаговременно.
В тот же OpenVPN PKI тоже не прямо жёстко зашита — можно использовать статический ключ. Кстати тогда возникает вопрос про вайргард: если мне ещё и ключи нужно так скрупулёзно распространять, зачем мне тогда DH встроенный в wireguard? Чего б тогда сразу статический ключ не назначать, раз оно без внешних костылей или ручной работы не работает? В своей презентации они такой способ, кстати, и рекомендуют, как возможный способ достижения постквантового шифрования. Но в дикой природе реализации wireguard, поддерживающие статический ключ, мне не попадались пока.
Поэтому AzireVPN наряду с wireguard предлагает и SOCKS5 без шифрования, а, например, vpn.ac предлагает PPTP (с MPPE на шифре RC4) и L2TP/IPsec с PSK для аутентификации сервера, который знают все клиенты. Wireguard на слуху, вот они и подсуетились. А старые протоколы поддерживают потому что и на них есть спрос со стороны владельцев старого оборудования. То есть, это из-за спроса, а не из-за безопасности.
Ох, RC4 — это они зря)) Наверное, в нынешнее время любой калькулятор сможет в режиме реального времени расшифровывать этот поточный шифр.
Вероятнее всего, CF пилил эту реализацию для своего Cloudflare Warp, который недавно запустился. Это VPN для мобильных и wireguard туда отлично вписывается потому, что прочно держит соединение, тут лучше чем wireguard и правда не придумать. Кроме того CF ещё имеет кое-какие амбиции по борьбе с цензурой, а у wireguard обфусцированный протокол.
Кстати, в рассылке WireGuard поступали предложения изменить протокол так, чтобы DPI системам сложнее было обнаруживать и классифицировать траффик WG, но автор ни в какую не соглашается. Там же в рассылке упоминалось, что великий китайский файрволл уже умеет детектировать и блокировать траффик WG.
Так помимо блочного шифра транспортного канала, с которым проблем и так особо нет, в шифронабор входят вариации согласования ключей по Диффи-Хеллману, псевдослучайная функция и асимметричные ключи подписи, к которым обычно больше вопросов. Вот в вайргарде оно всё прибито гвоздями, в OpenVPN и других хотя бы пара рабочих вариантов есть. И по той причине, что в протоколе wireguard применяется обфускация точек эллиптической кривой, которая специфична для этой конкретной кривой, по-другому не будет, там можно весь шифронабор только разом сменить.
С блочным шифром канала, кстати, возникает довольно много проблем (BEAST, POODLE). Вернее, с правильным использованием шифра. Взять к примеру тот же GCM режим — достаточно использовать один и тот же initialization vector дважды с одним ключом шифрования, чтобы полностью скомпроментировать этот ключ. Многие реализации грешат (или грешили) тем, что использовали псевдослучайный IV, а так как в GCM режиме размер вектора всего 12 байт, то при использовании PRNG низкого качества не исключена была вероятность повторов.
А по поводу смены всего шифронабора — по сути как я и писал, даже в TLS почти тот же подход — либо обновляешься на новую несовместимую версию, либо используешь предыдущую уязвимую, надеясь, что все известные слабые шифронаборы отключены, и что при этом у сервера и клиента остался хоть один общий вариант шифро-параметров.
Общего решения, сохраняющего свойства wireguard, не найдётся точно, потому что обнажение публичных ключей идёт вразрез с целями протокола Noise. Wireguard использует паттерн IK протокола Noise, и для получения гарантий, которые он предоставляет, инициатор должен знать публичный ключ ответчика заблаговременно.
Можно предположить какой-нибудь вариант, например, при котором удостоверяющий центр аутентифицирует клиента и выдает ему временную пару public/private ключей для WireGuard, которые можно использовать аналогично токенам Kerberos. Конечно, тут возникает проблема в том, что удостоверяющий центр сам должен после этого передать временный публичный ключ на сервер WireGuard, а это идёт вразрез с принципами PKI. Но при этом на сервер WireGuard не попадают данные, позволяющие связать временный публичный ключ с конкретным клиентом.
Кстати тогда возникает вопрос про вайргард: если мне ещё и ключи нужно так скрупулёзно распространять, зачем мне тогда DH встроенный в wireguard?
Хотя бы для обеспечения perfect forward secrecy, чтобы при компроментации ключа WG, злоумышленник не смог расшифровать предыдущие сессии.
Но в дикой природе реализации wireguard, поддерживающие статический ключ, мне не попадались пока.
Статический ключ — имеется ввиду pre-shared key? Если да, то по крайней мере в kernel версии они поддерживается и в Veeam PN используется для дополнительной безопасности.
Кстати, в рассылке WireGuard поступали предложения изменить протокол так, чтобы DPI системам сложнее было обнаруживать и классифицировать траффик WG, но автор ни в какую не соглашается. Там же в рассылке упоминалось, что великий китайский файрволл уже умеет детектировать и блокировать траффик WG.А есть где прочитать? Для меня это имеет некоторое значение.
В отношении DPI, наверное, самая выгодная стратегия — быть неотличимым от HTTPS и прочих виды «легетимного» шифрованного трафика. Тем более что в самом TLS уже есть всё неоходимое для шифрования.
Я видел информацию об этом в рассылке WireGuard, постараюсь найти.
Вот, что смог найти по теме обфускации и/или DPI (было больше обсуждений на подобную тематику, но поиск по ключевым словам меня подвёл):
lists.zx2c4.com/pipermail/wireguard/2016-July/000184.html
lists.zx2c4.com/pipermail/wireguard/2018-September/003289.html
lists.zx2c4.com/pipermail/wireguard/2019-January/003817.html
lists.zx2c4.com/pipermail/wireguard/2016-July/000184.html
lists.zx2c4.com/pipermail/wireguard/2018-September/003289.html
lists.zx2c4.com/pipermail/wireguard/2019-January/003817.html
.
Sign up to leave a comment.
Решение Veeam PN и его новые возможности в версии 2.0