Тупейшая критика WireGuard. Ненависть

https://habr.com/ru/company/dcmiran/blog/492888/
Я сразу перейду к части где критикуется криптография в этой статье.

* "Это не есть большой недостаток, потому что VPN используют HMAC для
  создания целостности" -- это не так, потому что современные VPN-ы
  используют AEAD режимы шифрования, где нет HMAC и хэша как такового.
  Ладно, допустим, пропустим
* "ChaCha20 — это потоковый шифр, который легче внедрить в программное
  обеспечение. Он шифрует один бит за раз. Блочные протоколы, такие как
  AES, шифруют блок по 128 бит за раз" -- у ChaCha20 есть состояние в
  512-бит. Оно не шифрует по одному биту за раз, а делает XOR с выхлопом
  ChaCha20. Абсолютно точно также как это делают режимы шифрования для
  AES: -CTR или -GCM. Более того, сколько бит за раз обрабатывают -- не
  имеет никакой корреляции с кол-ом транзисторов. Автор несёт херню
  полную
* "Ожидалось, что AES-NI никогда не попадет в смартфоны" -- кем и когда
  ожидалось?
* "Для этого был разработан ChaCha20 — в качестве легкой и экономичной
  альтернативы, щадящей заряд батареи" -- а Бернштейн то знает что он
  разрабатывал Salsa20 (ChaCha20 -- одна фигня) для экономии батареи
  смартфонов?
* "Следовательно, я ожидаю, что AES превзойдет ChaCha20 в каждом
  отдельно взятом сценарии." -- ожидать автор может что угодно, да вот
  только тесты в реальной жизни демонстрируют что ChaCha20+Poly1305
  реально зачастую быстрее AES-GCM с AESNI ускорением

Отсюда, следовательно, очевидно, я могу сделать вывод и ожидать что
автор нихера не понимает что несёт и пытается рассуждать непойми о чём.
Salsa20 разрабатывали никоим образом не для конкуренции с AES и
используют его (а также ChaCha20) не только для экономии вычислительных
ресурсов. Стоит ли мне и дальше обсуждать выводы этого человека?

* "BLAKE2 является преемником BLAKE, финалиста SHA-3, который не выиграл
  из-за своего сходства с SHA-2." -- а авторы то знали что это была
  причина почему они не выиграли? Автор снова несёт херню. Если бы
  требовался отличный дизайн от Давье-Майера, то это было бы в условиях
  SHA3 конкурса
* "Я не уверен, можно ли было предвидеть это при разработке WireGuard,
  но сегодня факт того, что он гвоздями прибит к одному шифрованию — уже
  является недостатком, который может не очень хорошо повлиять на его
  работу." -- боюсь что разработчики множества современных
  криптографических решений как-раз придерживаются прямо
  противоположного мнения и считают это достоинством. Но сам же автор
  пишет: "Достижение консенсуса на тему того, какое шифрование
  использовать, делает протоколы типа IKE и TLS более сложными. Слишком
  сложными? Да, в TLS/SSL уязвимости встречаются достаточно часто, и
  альтернативы им нет." -- сам же говорит что они слишком сложны и
  именно из-за этого люди используют и пилят свои более простые
  протоколы, потому что основной враг безопасности в криптографии это
  сложность. Простота WireGuard говорит о его повышенной безопасности

    Представьте, что у вас есть VPN-сервер с 200 боевыми клиентами,
    где-то по всему миру. Это вполне стандартный сценарий использования.
    Если вам придется менять шифрование, вам нужно доставить обновление
    на все копии WireGuard на этих ноутбуках, смартфонах и так далее.
    Одновременно доставить. Это буквально невозможно. Администраторам,
    которые попытаются это сделать, потребуются месяцы для развертывания
    необходимых конфигураций, а средним компаниям буквально понадобятся
    годы на проведение подобного мероприятия.

    IPsec и OpenVPN предлагают функцию согласования шифров. Поэтому
    некоторое время, после которого вы включите новое шифрование, будет
    работать и старое. Благодаря этому текущие клиенты смогут обновиться
    до новой версии. После того, как обновление будет раскатано, вы
    просто выключите уязвимое шифрование. И все! Готово! вы
    восхитительны! А клиенты этого даже не заметят.

Тоже полный лютый бред. Почти во всех протоколах всегда указывается
версия протокола, чтобы можно было отличить их. Если нужно менять
шифрование, то... меняйте, кто мешает то, новые версии будут
использовать новый протокол. Вы даже можете слушать на одном порту и
старой и новой версией и по её номеру понимать какие алгоритмы/протоколы
использовать. Если ВЫ (подчёркиваю -- ВЫ) обновляете у клиентов софт, то
просто используйте другие endpoint-ы для соединения, где форсированно
используются новые алгоритмы. Как вариант.

То, что OpenVPN или IPsec умеет согласовывать шифры, не отменяет того
факта что какая-нибудь Windows до сих пор поддерживает только
3DES+HMAC-MD5, какой-нибудь racoon из FreeBSD не умеет AES-GCM, а сама
FreeBSD не умеет ESN -- фиг вы всё это соедините без обновления софта.
Я до сих пор, не смотря на согласование алгоритмов, в 2020-ом году вижу
что OpenVPN-ы регулярно работают до сих пор с Blowfish-ем.

Ну и последнее -- а за всю историю человечества и компьютеров, много
приходилось менять то алгоритмы? Даже 3DES с HMAC-MD5 -- до сих пор
неубиваемая и невзламываемая штука. Приходилось форсированно обновлять
TLS из-за BEAST или CRIME. Почему? Из-за сложности протокола, его
гибкости и ФАТАЛЬНОГО факапа во всей этой сложности. Единственное что
нужно менять это короткие RSA ключи. Но... зачастую это можно сделать не
изменяя протокол в принципе, просто начиная использовать более длинные
ключи прозрачно. Среди хороших протоколов НЕ было уже 30+ лет надобности
использовать новые алгоритмы из-за вопросов безопасности. А именно этот
аргумент автор статьи приводит чаще всего -- а аргумент на практике
просто не имеет смысла. И гибкость, которую автор так хочет, как-раз и
погубила безопасность TLS, сложность губила OpenSSL. Раздел у автора
называется "об игнорировании реальных проблем" -- которых (проблем) то и
нет, а вот надуманные и высосанные из пальца имеются.

* "Но даже не это самое главное, на что стоит обратить внимание согласно
  официальной документации проекта. Ведь главное — это скорость." --
  нет, автор статьи, главное в WireGuard это простота, что, по моему,
  было очевидно. Не выдумывай

Дальше целый экран посвящённый тому что корпорации типа Cisco сделали
вот так, а оно не совместимо. Да, WireGuard это не реализация IPsec, а
другой VPN. Какой смысл это обсуждать я не понимаю. Хочется Cisco
обмазаться -- будешь использовать то, что они реализовали, без
вариантов, без обсуждений, очевидно.

Дальше лютейшее непонимание шифрования блоками по 64 KB.

    В сборке WireGuard для Linux он получает преимущество, используя GSO
    — Generic Segmentation Offloading. Благодаря ему, клиент создает
    огромный пакет размером 64 килобайта и шифрует/расшифровывает его за
    один подход. Таким образом, затраты на вызов и реализацию
    криптографических операций снижаются.

всё верно.

    Но, как это водится, в реальности не все так просто. Отправка такого
    большого пакета на сетевой адаптер требует, чтобы он бы был нарезан
    на множество меньших пакетов. Обычный размер отправления составляет
    1500 байт. То есть наш гигант в 64 килобайта будет разделен на 45
    пакетов (1240 байт информации и 20 байт IP-заголовка). Затем, на
    некоторое время они полностью заблокируют работу сетевого адаптера,
    потому что они должны быть отправлены вместе и сразу. В итоге это
    приведет к скачку приоритета, а такие пакеты, как, например, VoIP,
    будут поставлены в очередь ожидания.

Вот мне интересно кто это так требует что все фрагменты должны быть
отправлены "вместе и сразу"? Не, ну правда, лютый бред. Автор, ау, это
Интернет, где царит IP протокол, где пакеты передаются по сетям, в
общем случае, полностью независимо. Всем (технике) пофиг как ты
отправишь пакеты на сетевой адаптер, потому что на первом же hop они
перетасуются и дойдут до получателя уж как повезёт (или вообще не
дойдут). Ну а что такое "скачок приоритета"... я вообще даже примерно не
понимаю. Я не знаю конкретно что там делает WireGuard -- не исключено
что автор что-то выдумал, как сделал неоднократно с историей
криптографических примитивов.

Дальше длинный монолог о том, что WireGuard привёл показатель
производительности из слишком идеальных условий. Автор статьи пишет, что
"критерий применимости в реальной жизни абсолютно нарушен и, как я
думаю, автор проведенного «измерения» серьезно дискредитировал сам себя
по понятным причинам". Клёво: сам же придумал критерий которому надо
было удовлетворить и начал по нему оценивать. Очевидно автор статьи не в
курсе что выжать гигабит на старых добрых OpenVPN, OpenSSH, IPsec и
других популярных реализациях -- не просто. WireGuard показывает что им
это как нефиг делать. Речь про то, что у него огромный запас по
прочности, тогда как другие на практике и гигабит то с трудом выжмут. А
если захочется 10 GbE сеть обезопашивать? Вот тут то WireGuard и
намекает что с ним без хитростей возможно из коробки это просто
получится сделать.

    Для того, чтобы WireGuard стал конкурентным, ему нужно добавить хотя
    бы настройку IP-адреса и конфигурацию маршрутизации и DNS.

эээ, кхм... ну ok, даже не знаю как это комментировать. Для всего этого
уже уйму лет вроде бы есть специализированные для этого протоколы (DHCP
например), а IPv6 SLAAC просто из коробки позволит это автоматом всё
сделать. Добавлять это в VPN протокол? Даже бредом не могу это назвать,
это уже больное воображение. Если бы такое в него добавили, то WireGuard
бы стал лично для меня неконкурентоспособным.

Но предыдущий абзац автора я привёл не полностью:

    Для того, чтобы WireGuard стал конкурентным, ему нужно добавить хотя
    бы настройку IP-адреса и конфигурацию маршрутизации и DNS. Очевидно,
    что именно для этого нужны зашифрованные каналы.

Вот для чего они нужны то, оказывается! Надо же! Ну раз для этого, то
да, WireGuard вообще не вариант. Редко я слышал подобные несуразные
заявления.

    Любая криптографическая защита рано или поздно взламывается и,
    соответственно, должна быть заменена или обновлена.

Давай, ломай 3DES. Криптографическая защита то, как раз, в преобладающем
меньшинстве случаев ломается. И среди этих случаев ломаются реализации
корявые, как правило. А появляются они из-за сложности. TLS сертификаты
X.509 использует -- значит атаковать будут успешно (это уже было) ASN.1
парсер, ибо этот парсер более сложен чем весь WireGuard протокол,
включая симметричные алгоритмы.

    IPsec де-факто является стандартом и поддерживается практически
    повсеместно. И он работает. И как бы это не выглядело, в теории,
    WireGuard в будущем может быть несовместим даже с разными версиями
    самого себя.

Тут я не согласен с тем, что IPsec "работает". С одним человеком я тут
переписывался и подружить strongSwan на FreeBSD с Windows машиной -- я
даже уже точно получилось ли или нет. Вроде получилось, но без PFS
свойства, что... далеко не всегда можно сказать что удовлетворительно.
Плюс это было на 3DES+HMAC-MD5, производительность которых оставляет
желать лучшего. Соединить компьютеры за NAT... удачи. Соединить
используя IKEv1 -- люди будут радоваться и прыгать когда оно заработает,
так как большинство попыток будут приводить к неудаче, если параметры не
указывать зеркально. Да и вообще использовать IPsec без IPv6... страдание.

В общем, негодую всему этому написанному бреду. Точнее тому, что ведь в
него будут тыкать пользователи и считать WireGuard плохим.

Не хочу сказать что я рекомендую его использовать, так как сам я
однозначно поклонник IKEv2+ESP (IPsec), но меня берёт красота,
продуманность, гибкость инфраструктуры с ним. 99.9% пользователям ничего
из этого не надо и WireGuard их полностью удовлетворит с лихвой и будет
куда лучшим решением.