Вместо тяжеловесной std::function зачастую возможно использовать более легковесные non-owning non-allocating аналоги, например llvm::function_ref из проекта LLVM.
Мне тоже звонил МегаФон с точно таким же предложением. Сразу почувствовал подвох, и прервал словесный поток, сказав, что меня это не интересует. Видимо, придётся переходить к другому оператору — терпеть не могу, когда из меня пытаются сделать идиота.
Ещё было бы неплохо упомянуть о существовании UTF-16LE / UTF-16BE, а также упомянуть, что UTF-8 всегда кодируется единообразно, несмотря на порядок байт хост системы, в чём несомненный плюс этой кодировки по сравнению с UTF-16.
Поэтому 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 используется для дополнительной безопасности.
Я не большой фанат 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 :-)
Хорошая статья! Я бы ещё упомянул модуль GNUInstallDirs — мне кажется, что это более правильный способ указания target install directories. Плюс, для полноты картины можно подробнее рассказать о тестировании (add_test, etc.).
Я ничего не имею против самих корутин, даже наоборот. Мне до боли в глазах не нравятся префиксы co_ в зарезервированных словах) Угнетают моё чувство прекрасного, так сказать.
Пусть икается тем (ладно-ладно, только Гору Нишанову ;-)), кто решил использовать co_async/co_yield в качестве зарезервированных слов для coroutines. Ну почему не async/yield, как во всех других языках? Ведь были же достойные альтернативы (от того же самого Christopher Kohlhoff — автора библиотеки Boost.Asio), но Microsoft как обычно продавила своё решение…
Вовремя предать - это не предать, а предвидеть. (С)
Это интернет, малыш. Тут могут послать нахрен.
Прокомментируете? https://habr.com/ru/company/itsoft/blog/589037/
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
Ох, RC4 — это они зря)) Наверное, в нынешнее время любой калькулятор сможет в режиме реального времени расшифровывать этот поточный шифр.
Кстати, в рассылке WireGuard поступали предложения изменить протокол так, чтобы DPI системам сложнее было обнаруживать и классифицировать траффик WG, но автор ни в какую не соглашается. Там же в рассылке упоминалось, что великий китайский файрволл уже умеет детектировать и блокировать траффик WG.
С блочным шифром канала, кстати, возникает довольно много проблем (BEAST, POODLE). Вернее, с правильным использованием шифра. Взять к примеру тот же GCM режим — достаточно использовать один и тот же initialization vector дважды с одним ключом шифрования, чтобы полностью скомпроментировать этот ключ. Многие реализации грешат (или грешили) тем, что использовали псевдослучайный IV, а так как в GCM режиме размер вектора всего 12 байт, то при использовании PRNG низкого качества не исключена была вероятность повторов.
А по поводу смены всего шифронабора — по сути как я и писал, даже в TLS почти тот же подход — либо обновляешься на новую несовместимую версию, либо используешь предыдущую уязвимую, надеясь, что все известные слабые шифронаборы отключены, и что при этом у сервера и клиента остался хоть один общий вариант шифро-параметров.
Можно предположить какой-нибудь вариант, например, при котором удостоверяющий центр аутентифицирует клиента и выдает ему временную пару public/private ключей для WireGuard, которые можно использовать аналогично токенам Kerberos. Конечно, тут возникает проблема в том, что удостоверяющий центр сам должен после этого передать временный публичный ключ на сервер WireGuard, а это идёт вразрез с принципами PKI. Но при этом на сервер WireGuard не попадают данные, позволяющие связать временный публичный ключ с конкретным клиентом.
Хотя бы для обеспечения perfect forward secrecy, чтобы при компроментации ключа WG, злоумышленник не смог расшифровать предыдущие сессии.
Статический ключ — имеется ввиду pre-shared key? Если да, то по крайней мере в kernel версии они поддерживается и в Veeam PN используется для дополнительной безопасности.
Вообще, проводилось множество исследований криптостойкости WireGuard, как конкретной реализации, так и самого протокола. Навскидку, вот и вот. К тому же, аудит 4000 строк кода не в пример легче, чем аудит сотен тысяч.
Кроме того, WireGuard (по крайней мере kernel версия) использует реализацию крипто-примитивов и самого протокола, сгенерированных с использованием методов формальной верификации. Неплохо зная внутреннее устройство OpenVPN, я даже не могу представить, чтобы можно было полностью формально верифицировать или доказать криптостойкость протокола OpenVPN, хотя попытки были, например вот тут.
Множество, только абсолютное большинство из них уже устарело. Из тех шифров, которые удовлетворяют современным требованиям я бы назвал только 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 тоже можно придумать реализацию PKI, благо клиенты и так аутентифицируются по публичным/приватным ключам, которые суть есть Curve25519, так что можно раздавать клиентам те же ECC SSL сертификаты. То, что поддержка PKI не зашита в протокол WireGuard по-моему только плюс. Это, конечно, может быть минусом для корпоративного сектора, но думаю и там в скором времени найдётся решение.
При этом о поддержкe WireGuard и предоставлении сервисов на его основе уже заявило большинство крупнейших VPN провайдеров. А Cloudflare, например, вообще свою реализацию WireGuard протокола на Rust написали.
Насчёт сравнения с OpenVPN я бы поспорил. Реализация протокола поверх UDP в OpenVPN довольно примитивна: обычное скользящее окно фиксированного размера (на 8 пакетов если правильно помню), с возможностью подтверждения доставки сразу нескольких пакетов. Реализация сетевого взаимодействия в WireGuard тоже далека от оптимальной, но в отличие от OpenVPN, тут есть возможность использовать все доступные CPU для шифрования и обработки пакетов. OpenVPN же в версии 2.X все данные всегда обрабатывает в однопоточном режиме. Версия 3.X, в которой добавлена поддержка многопоточности, уже более 7 лет находится в состоянии разработки, ни одного релиза так до сих пор и не было.
Тут, конечно, только время покажет, но лично я голосую за WireGuard :-)