В последнее время WireGuard привлекает к себе большое внимание, фактически — это новая «звезда» среди VPN. Но так ли он хорош, как кажется? Я хотел бы обсудить некоторые наблюдения и рассмотреть реализацию WireGuard, чтобы рассказать, почему он не является решением, которое заменит IPsec или OpenVPN.
В этой статье я хотел бы развенчать некоторые мифы [вокруг WireGuard]. Да, читать придется долго, так что если вы еще не заварили себе чашечку чая или кофе, то самое время это сделать. Еще я бы хотел сказать спасибо Питеру за корректуру моих хаотичных мыслей.
Я не ставлю себе цель дискредитировать разработчиков WireGuard, обесценить их усилия или идеи. Их продукт — рабочий, но лично я считаю, что он представлен совершенно не тем, чем является на самом деле — представлен как замена IPsec и OpenVPN, которой на самом деле сейчас просто не существует.
В качестве примечания хочется добавить, что ответственность за такое позиционирование WireGuard несут СМИ, которые о нем рассказывали, а не сам проект или его создатели.
В последнее время на тему ядра Linux было не слишком много хороших новостей. Так, нам рассказали о чудовищных уязвимостях процессора, которые были нивелированы программным способом, а Линус Торвальдс рассказывал об этом слишком грубо и скучно, утилитарным языком разработчика. Планировщик или сетевой стек нулевого уровня — тоже не слишком понятные темы для глянцевых журналов. И тут появляется WireGuard.
На бумаге все звучит здорово: захватывающая воображение новая технология.
Но давайте посмотрим на нее чуть внимательнее.
Эта статья основана на официальной документации WireGuard, которую написал Джейсон Доненфельд. Там он объясняет концепцию, цель и техническую реализацию [WireGuard] в ядре Linux.
Первое предложение гласит:
Конечно, главное достоинство всех новых технологий — это их простота [в сравнении с предшественниками]. Но VPN также должен быть эффективным и безопасным.
И что дальше?
Если вы скажете, что вам [от VPN] нужно не это, то на этом чтение можно заканчивать. Однако я замечу, что такие задачи ставятся перед любой другой технологией туннелирования.
Самое интересное из приведенной выше цитаты кроется в словах «в большинстве случаев», которые, само собой, прессой были проигнорированы. И вот, мы там, где оказались из-за созданного этой небрежностью хаоса — в этой статье.
Нет. Здесь просто нет шансов, что крупные вендоры, такие как Cisco, Juniper и другие приобретут для своих продуктов WireGuard. Они не «запрыгивают в мимо проходящие поезда» на ходу, если на это нет какой-то большой необходимости. Позже я расскажу о некоторых причинах, по которым они, вероятно, не смогут установить на борт своих продуктов WireGuard, даже если бы захотели.
Нет. Прямо сейчас в WireGuard не реализовано огромное количество важных функций, чтобы он смог сделать что-то подобное. Например, он не может использовать динамические IP-адрес на стороне сервера туннеля, и уже только это ломает весь сценарий подобного использования продукта.
IPFire часто используется для дешевых интернет-каналов, например, для DSL или кабельного соединения. Это имеет смысл для малого или среднего бизнеса, которому не нужно быстрое оптоволокно. [Примечание от переводчика: не стоит забывать, что в плане связи Россия и некоторые страны СНГ находятся далеко впереди Европы и США, потому что мы начали строить свои сети намного позже и с приходом Ethernet и оптоволоконных сетей в качестве стандарта, нам было проще перестроиться. В тех же странах ЕС или США, xDSL широкополосный доступ на скорости 3-5 Мбит/с — до сих пор всеобщая норма, а оптоволоконное подключение стоит каких-то нереальных по нашим меркам денег. Поэтому автор статьи и говорит о DSL или кабельном подключении, как о норме, а не дремучей старине.] Однако DSL, кабельные, LTE (и другие беспроводные методы доступа) имеют динамические IP-адреса. Конечно, временами они меняются не часто, но все же меняются.
Существует подпроект под названием «wg-dynamic», который добавляет демон пользовательского пространства для преодоления этого недостатка. Огромная проблема пользовательского сценария, описанного выше — это усугубление ситуации динамической IPv6-адресацией.
С точки зрения дистрибьютора все это тоже выглядит не очень. Одна из целей разработки было сохранить простоту и чистоту протокола.
К сожалению, все это на самом деле стало слишком простым и примитивным, так что нам приходится использовать дополнительное ПО, чтобы вся эта конструкция была жизнеспособной в условиях реальной эксплуатации.
Пока нет. Я не говорю, что WireGuard никогда не будет хорошей альтернативой для проброса туннеля между двумя точками, но пока он — всего лишь альфа-версия продукта, которым должен стать.
Но что тогда на самом деле он делает? Действительно ли IPsec настолько сложнее в эксплуатации?
Очевидно, что нет. Поставщик IPsec продумал этот момент и поставляет свой продукт вместе с интерфейсом, например, с IPFire.
Для настройки VPN-туннеля через IPsec вам потребуется пять наборов данных, которые нужно будет внести в конфигурацию: ваш собственный публичный IP-адрес, публичный IP-адрес принимающей стороны, подсети, которые вы хотите сделать общедоступными через это VPN-соединение и pre-shared ключ. Таким образом, VPN настраивается в течение нескольких минут и он совместим с любым вендором.
К сожалению, в этой истории есть несколько исключений. Каждый, кто пытался пробросить VPN-туннель через IPsec к машине на OpenBSD, понимает, о чем я говорю. Есть еще пара болезненных примеров, но на самом деле положительной практики использования IPsec намного и намного больше.
Конечный потребитель не должен беспокоиться о сложности протокола.
Если бы мы жили в мире, где это было реальной заботой юзера, то мы уже давно избавились бы от SIP, H.323, FTP и других, созданных более десяти лет назад протоколов, которые плохо работают с NAT.
Есть причины, по которым IPsec сложнее, чем WireGuard: он делает намного больше вещей. Например, аутентификация пользователя с использованием логина/пароля или SIM-карты с EAP. У него расширенная возможность добавления новых криптографических примитивов.
А у WireGuard этого нет.
И это означает, что WireGuard в какой-то момент сломается, потому что один из криптографических примитивов ослабнет или будет полностью скомпрометирован. Автор техдокументации говорит об этом так:
Последнее предложение абсолютно верно.
Достижение консенсуса на тему того, какое шифрование использовать, делает протоколы типа IKE и TLS более сложными. Слишком сложными? Да, в TLS/SSL уязвимости встречаются достаточно часто, и альтернативы им нет.
Представьте, что у вас есть VPN-сервер с 200 боевыми клиентами, где-то по всему миру. Это вполне стандартный сценарий использования. Если вам придется менять шифрование, вам нужно доставить обновление на все копии WireGuard на этих ноутбуках, смартфонах и так далее. Одновременно доставить. Это буквально невозможно. Администраторам, которые попытаются это сделать, потребуются месяцы для развертывания необходимых конфигураций, а средним компаниям буквально понадобятся годы на проведение подобного мероприятия.
IPsec и OpenVPN предлагают функцию согласования шифров. Поэтому некоторое время, после которого вы включите новое шифрование, будет работать и старое. Благодаря этому текущие клиенты смогут обновиться до новой версии. После того, как обновление будет раскатано, вы просто выключите уязвимое шифрование. И все! Готово! вы восхитительны! А клиенты этого даже не заметят.
На самом деле это очень распространенный кейс для больших развертываний, и даже OpenVPN испытывает в этом некоторые трудности. Обратная совместимость важна, и хотя вы используете более слабое шифрование, для многих это не становится причиной закрытия бизнеса. Потому что это приведет к параличу работы сотен клиентов из-за неспособности выполнять свою работу.
Команда WireGuard сделала свой протокол проще, но совершенно непригодным для людей, которые не имеют постоянного контроля над обоими пирами своего туннеля. По моему опыту именно такой сценарий — наиболее распространенный.
Но что это за интересное новое шифрование, которое использует WireGuard?
ChaCha20-Poly1305 стандартизирован для IPsec и OpenVPN (через TLS).
Очевидно, что разработка Даниэля Бернштейна используется очень часто. BLAKE2 является преемником BLAKE, финалиста SHA-3, который не выиграл из-за своего сходства с SHA-2. Если бы SHA-2 был взломан, была большая вероятность, что и BLAKE окажется скомпрометирован.
IPsec и OpenVPN не нуждаются в SipHash из-за их дизайна. Таким образом, единственное, что в настоящее время не может использоваться с ними, это BLAKE2, и то, только пока он не будет стандартизирован. Это не есть большой недостаток, потому что VPN используют HMAC для создания целостности, которая считается сильным решением даже в связке с MD5.
Так я пришел к выводу, что во всех VPN используется практически один и тот же набор криптографических инструментов. Поэтому WireGuard не более и не менее безопасен, чем любые другие актуальные продукты, когда дело доходит до шифрования или целостности передаваемых данных.
Но даже не это самое главное, на что стоит обратить внимание согласно официальной документации проекта. Ведь главное — это скорость.
Если кратко: нет, не быстрее.
ChaCha20 — это потоковый шифр, который легче внедрить в программное обеспечение. Он шифрует один бит за раз. Блочные протоколы, такие как AES, шифруют блок по 128 бит за раз. Для реализации аппаратной поддержки потребуется гораздо больше транзисторов, поэтому более крупные процессоры поставляются с AES-NI — расширением набора команд, которое выполняет некоторые задачи процесса шифрования для его ускорения.
Ожидалось, что AES-NI никогда не попадет в смартфоны [а оно попало, — прим. пер.]. Для этого был разработан ChaCha20 — в качестве легкой и экономичной альтернативы, щадящей заряд батареи. Поэтому для вас может стать новостью, что каждый смартфон, который вы можете сегодня приобрести, имеет то или иное ускорение для AES и работает с этим шифрованием быстрее и с меньшим энергопотреблением, чем с ChaCha20.
Очевидно, что практически каждый процессор для настольных ПК / серверов, купленный за последние пару лет, имеет AES-NI.
Следовательно, я ожидаю, что AES превзойдет ChaCha20 в каждом отдельно взятом сценарии. В официальной документации WireGuard упоминается, что благодаря AVX512 ChaCha20-Poly1305 будет превосходить AES-NI, но это расширение набора команд будет доступно только на больших процессорах, что опять-таки не поможет с меньшим и мобильным оборудованием, которое всегда будет быстрее работать с AES-NI.
Я не уверен, можно ли было предвидеть это при разработке WireGuard, но сегодня факт того, что он гвоздями прибит к одному шифрованию — уже является недостатком, который может не очень хорошо повлиять на его работу.
IPsec позволяет свободно выбирать, какое шифрование лучше всего подходит для вашего случая. И само собой, это необходимо, если вы, например, хотите передать 10 и более гигабайт данных через VPN-соединение.
Хотя WireGuard выбрал современный протокол шифрования, это уже вызывает массу проблем. И вот, вместо того, чтобы использовать то, что поддерживается ядром из коробки, интеграция WireGuard откладывалась годами из-за отсутствия этих примитивов в Linux.
Я не до конца в курсе, какова ситуация в других операционных системах, но вероятно, она не сильно отличается от ситуации с Linux.
К сожалению, каждый раз, когда клиент просит меня настроить ему VPN-соединение, я сталкиваюсь с тему, что они используют устаревшие учетные данные и шифрование. 3DES в связке с MD5 — все еще распространенная практика, также как ASE-256 и SHA1. И хотя последний чуть лучше — это не то, чем стоит пользоваться в 2020 году.
Для обмена ключами всегда используется RSA — медленный, но достаточно безопасный инструмент.
Мои клиенты связаны с таможенными органами и другими госорганизациями и учреждениями, а также с крупными корпорациями, названия которых знают по всему миру. Все они используют форму запроса, которая была создана десятилетия назад, а возможность использования SHA-512 просто никогда не добавлялась. Я не могу сказать, что это как-то явно влияет на технологический прогресс, но очевидно, это замедляет корпоративные процесс.
Мне больно это видеть, потому что IPsec поддерживает эллиптические кривые на вскидку так с года 2005. Curve25519 также новее и доступен для использования. Еще есть альтернативы AES, такие как Camellia и ChaCha20, но, очевидно, не все из них поддерживаются крупными поставщиками, такими как Cisco и прочими.
И люди этим пользуются. Есть много комплектов Cisco, есть множество комплектов, созданных для работы с Cisco. Они являются лидерами рынка в этом сегменте и не очень заинтересованы в каких-либо инновациях.
Да, ситуация [в корпоративном сегменте] ужасна, но мы не увидим каких-либо изменений из-за WireGuard. Производители, вероятно, никогда не выявят каких-либо проблем с производительностью уже используемого инструментария и шифрования, не увидят проблем при использовании IKEv2 — и поэтому они не ищут альтернатив.
Вообще, вы задумывались когда-нибудь об отказе от Cisco?
А теперь перейдем к бенчмаркам из документации WireGuard. Хотя это [документация] не научная статья, я все же ожидал от разработчиков более научного подхода, либо использования научного подхода в качестве эталона. Любые бенчмарки бесполезны, если их нельзя воспроизвести, и еще более они бесполезны, когда получены в лабораторных условиях.
В сборке WireGuard для Linux он получает преимущество, используя GSO — Generic Segmentation Offloading. Благодаря ему, клиент создает огромный пакет размером 64 килобайта и шифрует/расшифровывает его за один подход. Таким образом, затраты на вызов и реализацию криптографических операций снижаются. Если вы хотите максимизировать пропускную способность вашего VPN-соединения — это хорошая идея.
Но, как это водится, в реальности не все так просто. Отправка такого большого пакета на сетевой адаптер требует, чтобы он бы был нарезан на множество меньших пакетов. Обычный размер отправления составляет 1500 байт. То есть наш гигант в 64 килобайта будет разделен на 45 пакетов (1240 байт информации и 20 байт IP-заголовка). Затем, на некоторое время они полностью заблокируют работу сетевого адаптера, потому что они должны быть отправлены вместе и сразу. В итоге это приведет к скачку приоритета, а такие пакеты, как, например, VoIP, будут поставлены в очередь ожидания.
Таким образом, высокая пропускная способность, о которой так смело заявляет WireGuard, достигается за счет замедления сетевой работы других приложений. И команда WireGuard уже подтвердила этот мой вывод.
Но давайте двигаться дальше.
Согласно бенчмаркам в техдокументации, соединение показывает пропускную способность в 1011 Мбит/с.
Впечатляет.
Особенно это впечатляет из-за того, что максимальная теоретическая пропускная способность одного гигабитного Ethernet-подключения составляет 966 Мбит/с при размере пакета в 1500 байт минус 20 байт на IP-заголовок, 8 байт на UDP-заголовок и 16 байт на заголовок самого WireGuard. Есть еще один заголовок IP в инкапсулированном пакете и другой — в TCP на 20 байт. Так откуда появилась эта дополнительная пропускная способность?
С огромными фреймами и преимуществами GSO, о которых мы говорили выше, теоретический максимум при размере фрейма в 9000 байт будет равен 1014 Мбит/с. Обычно такая пропускная способность в реальности недостижима, потому что связана с большими трудностями. Таким образом, я могу только предположить, что тест был выполнен с использованием еще более жирных фреймов с превышением размера в 64 килобайта с теоретическим максимумом в 1023 Мбит/с, что поддерживается только некоторыми сетевыми адаптерами. Но это абсолютно неприменимо в реальных условиях, либо может использоваться только между двумя напрямую соединенными между собой станциями, исключительно в рамках тестового стенда.
Но так как VPN-туннель пробрасывается между двумя хостами с помощью интернет-соединения, которое вообще не поддерживает большие фреймы, достигнутый на стенде результат не может быть принят за эталон. Это просто нереальное лабораторное достижение, которое невозможно и неприменимо в реальных боевых условиях.
Даже сидя в дата-центре я не смог бы перебрасывать фреймы размером более 9000 байт.
Критерий применимости в реальной жизни абсолютно нарушен и, как я думаю, автор проведенного «измерения» серьезно дискредитировал сам себя по понятным причинам.
На сайте WireGuard много говорится о контейнерах и становится понятно, для чего он на самом деле предназначен.
Простой и быстрый VPN, который не требует настройки и может быть развернут и настроен массивными инструментами оркестровки, как, например, у Amazon в их облаке. Конкретно Amazon использует новейшие аппаратные функции, о которых я упоминал ранее, например — AVX512. Делается это для того, чтобы ускорить работу и не привязываться к x86 или любой другой архитектуре.
Они оптимизируют пропускную способность и пакеты, размер которых превышает 9000 байт — это получатся огромные инкапсулированные фреймы для общения контейнеров между собой, или для операций резервного копирования, создания снапшотов или развертывая этих самых контейнеров Даже динамические IP-адреса никак не повлияют на работу WireGuard в случае описанного мною сценария.
Неплохо сыграно. Блестящая реализация и очень тонкий, почти эталонный протокол.
Но он просто не подходит для мира за пределами полностью контролируемого вами дата-центра. Если же вы рискнете и начнете использовать WireGuard, вам придется идти на постоянные компромиссы при разработке и реализации протокола шифрования.
Мне несложно сделать вывод о том, что WireGuard пока не готов.
Он задумывался как облегченное и быстрое решение ряда проблем у уже существующих решений. К сожалению, ради этих решений он пожертвовал многими функциями, которые будут актуальны для большинства пользователей. Именно поэтому он не может заменить IPsec или OpenVPN.
Для того, чтобы WireGuard стал конкурентным, ему нужно добавить хотя бы настройку IP-адреса и конфигурацию маршрутизации и DNS. Очевидно, что именно для этого нужны зашифрованные каналы.
Безопасность — мой главный приоритет, и сейчас у меня нет оснований полагать, что IKE или TLS как-то скомпрометированы или поломаны. Современное шифрование поддерживается в них обоих, и они были проверены десятилетиями эксплуатации. Если что-то новее не значит, что это что-то — лучше.
Функциональная совместимость крайне важна, когда вы связываетесь с третьими лицами, станции которых вы не контролируете. IPsec де-факто является стандартом и поддерживается практически повсеместно. И он работает. И как бы это не выглядело, в теории, WireGuard в будущем может быть несовместим даже с разными версиями самого себя.
Любая криптографическая защита рано или поздно взламывается и, соответственно, должна быть заменена или обновлена.
Отрицание всех этих фактов и слепое желание использовать WireGuard для подключения вашего iPhone к домашней рабочей станции — это просто мастер-класс по засовыванию головы в песок.
В этой статье я хотел бы развенчать некоторые мифы [вокруг WireGuard]. Да, читать придется долго, так что если вы еще не заварили себе чашечку чая или кофе, то самое время это сделать. Еще я бы хотел сказать спасибо Питеру за корректуру моих хаотичных мыслей.
Я не ставлю себе цель дискредитировать разработчиков WireGuard, обесценить их усилия или идеи. Их продукт — рабочий, но лично я считаю, что он представлен совершенно не тем, чем является на самом деле — представлен как замена IPsec и OpenVPN, которой на самом деле сейчас просто не существует.
В качестве примечания хочется добавить, что ответственность за такое позиционирование WireGuard несут СМИ, которые о нем рассказывали, а не сам проект или его создатели.
В последнее время на тему ядра Linux было не слишком много хороших новостей. Так, нам рассказали о чудовищных уязвимостях процессора, которые были нивелированы программным способом, а Линус Торвальдс рассказывал об этом слишком грубо и скучно, утилитарным языком разработчика. Планировщик или сетевой стек нулевого уровня — тоже не слишком понятные темы для глянцевых журналов. И тут появляется WireGuard.
На бумаге все звучит здорово: захватывающая воображение новая технология.
Но давайте посмотрим на нее чуть внимательнее.
Техническая документация WireGuard
Эта статья основана на официальной документации WireGuard, которую написал Джейсон Доненфельд. Там он объясняет концепцию, цель и техническую реализацию [WireGuard] в ядре Linux.
Первое предложение гласит:
WireGuard [...] стремится заменить как IPsec в большинстве кейсов его использования, так другие популярные решения на основе пользовательского пространства и/или TLS, такие как OpenVPN, при этом являясь более безопасным, производительным и простым в использовании [инструментом].
Конечно, главное достоинство всех новых технологий — это их простота [в сравнении с предшественниками]. Но VPN также должен быть эффективным и безопасным.
И что дальше?
Если вы скажете, что вам [от VPN] нужно не это, то на этом чтение можно заканчивать. Однако я замечу, что такие задачи ставятся перед любой другой технологией туннелирования.
Самое интересное из приведенной выше цитаты кроется в словах «в большинстве случаев», которые, само собой, прессой были проигнорированы. И вот, мы там, где оказались из-за созданного этой небрежностью хаоса — в этой статье.
Станет ли WireGuard заменой моей [IPsec] VPN-связи между сайтами?
Нет. Здесь просто нет шансов, что крупные вендоры, такие как Cisco, Juniper и другие приобретут для своих продуктов WireGuard. Они не «запрыгивают в мимо проходящие поезда» на ходу, если на это нет какой-то большой необходимости. Позже я расскажу о некоторых причинах, по которым они, вероятно, не смогут установить на борт своих продуктов WireGuard, даже если бы захотели.
Перенесет ли WireGuard мой RoadWarrior с ноутбука в дата-центр?
Нет. Прямо сейчас в WireGuard не реализовано огромное количество важных функций, чтобы он смог сделать что-то подобное. Например, он не может использовать динамические IP-адрес на стороне сервера туннеля, и уже только это ломает весь сценарий подобного использования продукта.
IPFire часто используется для дешевых интернет-каналов, например, для DSL или кабельного соединения. Это имеет смысл для малого или среднего бизнеса, которому не нужно быстрое оптоволокно. [Примечание от переводчика: не стоит забывать, что в плане связи Россия и некоторые страны СНГ находятся далеко впереди Европы и США, потому что мы начали строить свои сети намного позже и с приходом Ethernet и оптоволоконных сетей в качестве стандарта, нам было проще перестроиться. В тех же странах ЕС или США, xDSL широкополосный доступ на скорости 3-5 Мбит/с — до сих пор всеобщая норма, а оптоволоконное подключение стоит каких-то нереальных по нашим меркам денег. Поэтому автор статьи и говорит о DSL или кабельном подключении, как о норме, а не дремучей старине.] Однако DSL, кабельные, LTE (и другие беспроводные методы доступа) имеют динамические IP-адреса. Конечно, временами они меняются не часто, но все же меняются.
Существует подпроект под названием «wg-dynamic», который добавляет демон пользовательского пространства для преодоления этого недостатка. Огромная проблема пользовательского сценария, описанного выше — это усугубление ситуации динамической IPv6-адресацией.
С точки зрения дистрибьютора все это тоже выглядит не очень. Одна из целей разработки было сохранить простоту и чистоту протокола.
К сожалению, все это на самом деле стало слишком простым и примитивным, так что нам приходится использовать дополнительное ПО, чтобы вся эта конструкция была жизнеспособной в условиях реальной эксплуатации.
WireGuard так просто пользоваться?
Пока нет. Я не говорю, что WireGuard никогда не будет хорошей альтернативой для проброса туннеля между двумя точками, но пока он — всего лишь альфа-версия продукта, которым должен стать.
Но что тогда на самом деле он делает? Действительно ли IPsec настолько сложнее в эксплуатации?
Очевидно, что нет. Поставщик IPsec продумал этот момент и поставляет свой продукт вместе с интерфейсом, например, с IPFire.
Для настройки VPN-туннеля через IPsec вам потребуется пять наборов данных, которые нужно будет внести в конфигурацию: ваш собственный публичный IP-адрес, публичный IP-адрес принимающей стороны, подсети, которые вы хотите сделать общедоступными через это VPN-соединение и pre-shared ключ. Таким образом, VPN настраивается в течение нескольких минут и он совместим с любым вендором.
К сожалению, в этой истории есть несколько исключений. Каждый, кто пытался пробросить VPN-туннель через IPsec к машине на OpenBSD, понимает, о чем я говорю. Есть еще пара болезненных примеров, но на самом деле положительной практики использования IPsec намного и намного больше.
О сложности протокола
Конечный потребитель не должен беспокоиться о сложности протокола.
Если бы мы жили в мире, где это было реальной заботой юзера, то мы уже давно избавились бы от SIP, H.323, FTP и других, созданных более десяти лет назад протоколов, которые плохо работают с NAT.
Есть причины, по которым IPsec сложнее, чем WireGuard: он делает намного больше вещей. Например, аутентификация пользователя с использованием логина/пароля или SIM-карты с EAP. У него расширенная возможность добавления новых криптографических примитивов.
А у WireGuard этого нет.
И это означает, что WireGuard в какой-то момент сломается, потому что один из криптографических примитивов ослабнет или будет полностью скомпрометирован. Автор техдокументации говорит об этом так:
Стоит отметить, что WireGuard криптографически самоуверен. Ему намеренно не хватает гибкости шифров и протоколов. Если в низлежащих примитивах будут обнаружены серьезные дыры, все конечные точки потребуется обновить. Как видно из продолжающегося потока уязвимостей SLL/TLS, гибкость шифрования сейчас колоссально увеличилась.
Последнее предложение абсолютно верно.
Достижение консенсуса на тему того, какое шифрование использовать, делает протоколы типа IKE и TLS более сложными. Слишком сложными? Да, в TLS/SSL уязвимости встречаются достаточно часто, и альтернативы им нет.
Об игнорировании реальных проблем
Представьте, что у вас есть VPN-сервер с 200 боевыми клиентами, где-то по всему миру. Это вполне стандартный сценарий использования. Если вам придется менять шифрование, вам нужно доставить обновление на все копии WireGuard на этих ноутбуках, смартфонах и так далее. Одновременно доставить. Это буквально невозможно. Администраторам, которые попытаются это сделать, потребуются месяцы для развертывания необходимых конфигураций, а средним компаниям буквально понадобятся годы на проведение подобного мероприятия.
IPsec и OpenVPN предлагают функцию согласования шифров. Поэтому некоторое время, после которого вы включите новое шифрование, будет работать и старое. Благодаря этому текущие клиенты смогут обновиться до новой версии. После того, как обновление будет раскатано, вы просто выключите уязвимое шифрование. И все! Готово! вы восхитительны! А клиенты этого даже не заметят.
На самом деле это очень распространенный кейс для больших развертываний, и даже OpenVPN испытывает в этом некоторые трудности. Обратная совместимость важна, и хотя вы используете более слабое шифрование, для многих это не становится причиной закрытия бизнеса. Потому что это приведет к параличу работы сотен клиентов из-за неспособности выполнять свою работу.
Команда WireGuard сделала свой протокол проще, но совершенно непригодным для людей, которые не имеют постоянного контроля над обоими пирами своего туннеля. По моему опыту именно такой сценарий — наиболее распространенный.
Криптография!
Но что это за интересное новое шифрование, которое использует WireGuard?
WireGuard использует Curve25519 для обмена ключами, ChaCha20 для шифрования и Poly1305 для аутентификации данных. Также он работает с SipHash для хеш-ключей и BLAKE2 для хеширования.
ChaCha20-Poly1305 стандартизирован для IPsec и OpenVPN (через TLS).
Очевидно, что разработка Даниэля Бернштейна используется очень часто. BLAKE2 является преемником BLAKE, финалиста SHA-3, который не выиграл из-за своего сходства с SHA-2. Если бы SHA-2 был взломан, была большая вероятность, что и BLAKE окажется скомпрометирован.
IPsec и OpenVPN не нуждаются в SipHash из-за их дизайна. Таким образом, единственное, что в настоящее время не может использоваться с ними, это BLAKE2, и то, только пока он не будет стандартизирован. Это не есть большой недостаток, потому что VPN используют HMAC для создания целостности, которая считается сильным решением даже в связке с MD5.
Так я пришел к выводу, что во всех VPN используется практически один и тот же набор криптографических инструментов. Поэтому WireGuard не более и не менее безопасен, чем любые другие актуальные продукты, когда дело доходит до шифрования или целостности передаваемых данных.
Но даже не это самое главное, на что стоит обратить внимание согласно официальной документации проекта. Ведь главное — это скорость.
WireGuard быстрее других решений VPN?
Если кратко: нет, не быстрее.
ChaCha20 — это потоковый шифр, который легче внедрить в программное обеспечение. Он шифрует один бит за раз. Блочные протоколы, такие как AES, шифруют блок по 128 бит за раз. Для реализации аппаратной поддержки потребуется гораздо больше транзисторов, поэтому более крупные процессоры поставляются с AES-NI — расширением набора команд, которое выполняет некоторые задачи процесса шифрования для его ускорения.
Ожидалось, что AES-NI никогда не попадет в смартфоны [а оно попало, — прим. пер.]. Для этого был разработан ChaCha20 — в качестве легкой и экономичной альтернативы, щадящей заряд батареи. Поэтому для вас может стать новостью, что каждый смартфон, который вы можете сегодня приобрести, имеет то или иное ускорение для AES и работает с этим шифрованием быстрее и с меньшим энергопотреблением, чем с ChaCha20.
Очевидно, что практически каждый процессор для настольных ПК / серверов, купленный за последние пару лет, имеет AES-NI.
Следовательно, я ожидаю, что AES превзойдет ChaCha20 в каждом отдельно взятом сценарии. В официальной документации WireGuard упоминается, что благодаря AVX512 ChaCha20-Poly1305 будет превосходить AES-NI, но это расширение набора команд будет доступно только на больших процессорах, что опять-таки не поможет с меньшим и мобильным оборудованием, которое всегда будет быстрее работать с AES-NI.
Я не уверен, можно ли было предвидеть это при разработке WireGuard, но сегодня факт того, что он гвоздями прибит к одному шифрованию — уже является недостатком, который может не очень хорошо повлиять на его работу.
IPsec позволяет свободно выбирать, какое шифрование лучше всего подходит для вашего случая. И само собой, это необходимо, если вы, например, хотите передать 10 и более гигабайт данных через VPN-соединение.
Проблемы интеграции в Linux
Хотя WireGuard выбрал современный протокол шифрования, это уже вызывает массу проблем. И вот, вместо того, чтобы использовать то, что поддерживается ядром из коробки, интеграция WireGuard откладывалась годами из-за отсутствия этих примитивов в Linux.
Я не до конца в курсе, какова ситуация в других операционных системах, но вероятно, она не сильно отличается от ситуации с Linux.
Как выглядит реальность?
К сожалению, каждый раз, когда клиент просит меня настроить ему VPN-соединение, я сталкиваюсь с тему, что они используют устаревшие учетные данные и шифрование. 3DES в связке с MD5 — все еще распространенная практика, также как ASE-256 и SHA1. И хотя последний чуть лучше — это не то, чем стоит пользоваться в 2020 году.
Для обмена ключами всегда используется RSA — медленный, но достаточно безопасный инструмент.
Мои клиенты связаны с таможенными органами и другими госорганизациями и учреждениями, а также с крупными корпорациями, названия которых знают по всему миру. Все они используют форму запроса, которая была создана десятилетия назад, а возможность использования SHA-512 просто никогда не добавлялась. Я не могу сказать, что это как-то явно влияет на технологический прогресс, но очевидно, это замедляет корпоративные процесс.
Мне больно это видеть, потому что IPsec поддерживает эллиптические кривые на вскидку так с года 2005. Curve25519 также новее и доступен для использования. Еще есть альтернативы AES, такие как Camellia и ChaCha20, но, очевидно, не все из них поддерживаются крупными поставщиками, такими как Cisco и прочими.
И люди этим пользуются. Есть много комплектов Cisco, есть множество комплектов, созданных для работы с Cisco. Они являются лидерами рынка в этом сегменте и не очень заинтересованы в каких-либо инновациях.
Да, ситуация [в корпоративном сегменте] ужасна, но мы не увидим каких-либо изменений из-за WireGuard. Производители, вероятно, никогда не выявят каких-либо проблем с производительностью уже используемого инструментария и шифрования, не увидят проблем при использовании IKEv2 — и поэтому они не ищут альтернатив.
Вообще, вы задумывались когда-нибудь об отказе от Cisco?
Бенчмарки
А теперь перейдем к бенчмаркам из документации WireGuard. Хотя это [документация] не научная статья, я все же ожидал от разработчиков более научного подхода, либо использования научного подхода в качестве эталона. Любые бенчмарки бесполезны, если их нельзя воспроизвести, и еще более они бесполезны, когда получены в лабораторных условиях.
В сборке WireGuard для Linux он получает преимущество, используя GSO — Generic Segmentation Offloading. Благодаря ему, клиент создает огромный пакет размером 64 килобайта и шифрует/расшифровывает его за один подход. Таким образом, затраты на вызов и реализацию криптографических операций снижаются. Если вы хотите максимизировать пропускную способность вашего VPN-соединения — это хорошая идея.
Но, как это водится, в реальности не все так просто. Отправка такого большого пакета на сетевой адаптер требует, чтобы он бы был нарезан на множество меньших пакетов. Обычный размер отправления составляет 1500 байт. То есть наш гигант в 64 килобайта будет разделен на 45 пакетов (1240 байт информации и 20 байт IP-заголовка). Затем, на некоторое время они полностью заблокируют работу сетевого адаптера, потому что они должны быть отправлены вместе и сразу. В итоге это приведет к скачку приоритета, а такие пакеты, как, например, VoIP, будут поставлены в очередь ожидания.
Таким образом, высокая пропускная способность, о которой так смело заявляет WireGuard, достигается за счет замедления сетевой работы других приложений. И команда WireGuard уже подтвердила этот мой вывод.
Но давайте двигаться дальше.
Согласно бенчмаркам в техдокументации, соединение показывает пропускную способность в 1011 Мбит/с.
Впечатляет.
Особенно это впечатляет из-за того, что максимальная теоретическая пропускная способность одного гигабитного Ethernet-подключения составляет 966 Мбит/с при размере пакета в 1500 байт минус 20 байт на IP-заголовок, 8 байт на UDP-заголовок и 16 байт на заголовок самого WireGuard. Есть еще один заголовок IP в инкапсулированном пакете и другой — в TCP на 20 байт. Так откуда появилась эта дополнительная пропускная способность?
С огромными фреймами и преимуществами GSO, о которых мы говорили выше, теоретический максимум при размере фрейма в 9000 байт будет равен 1014 Мбит/с. Обычно такая пропускная способность в реальности недостижима, потому что связана с большими трудностями. Таким образом, я могу только предположить, что тест был выполнен с использованием еще более жирных фреймов с превышением размера в 64 килобайта с теоретическим максимумом в 1023 Мбит/с, что поддерживается только некоторыми сетевыми адаптерами. Но это абсолютно неприменимо в реальных условиях, либо может использоваться только между двумя напрямую соединенными между собой станциями, исключительно в рамках тестового стенда.
Но так как VPN-туннель пробрасывается между двумя хостами с помощью интернет-соединения, которое вообще не поддерживает большие фреймы, достигнутый на стенде результат не может быть принят за эталон. Это просто нереальное лабораторное достижение, которое невозможно и неприменимо в реальных боевых условиях.
Даже сидя в дата-центре я не смог бы перебрасывать фреймы размером более 9000 байт.
Критерий применимости в реальной жизни абсолютно нарушен и, как я думаю, автор проведенного «измерения» серьезно дискредитировал сам себя по понятным причинам.
Последний проблеск надежды
На сайте WireGuard много говорится о контейнерах и становится понятно, для чего он на самом деле предназначен.
Простой и быстрый VPN, который не требует настройки и может быть развернут и настроен массивными инструментами оркестровки, как, например, у Amazon в их облаке. Конкретно Amazon использует новейшие аппаратные функции, о которых я упоминал ранее, например — AVX512. Делается это для того, чтобы ускорить работу и не привязываться к x86 или любой другой архитектуре.
Они оптимизируют пропускную способность и пакеты, размер которых превышает 9000 байт — это получатся огромные инкапсулированные фреймы для общения контейнеров между собой, или для операций резервного копирования, создания снапшотов или развертывая этих самых контейнеров Даже динамические IP-адреса никак не повлияют на работу WireGuard в случае описанного мною сценария.
Неплохо сыграно. Блестящая реализация и очень тонкий, почти эталонный протокол.
Но он просто не подходит для мира за пределами полностью контролируемого вами дата-центра. Если же вы рискнете и начнете использовать WireGuard, вам придется идти на постоянные компромиссы при разработке и реализации протокола шифрования.
Вывод
Мне несложно сделать вывод о том, что WireGuard пока не готов.
Он задумывался как облегченное и быстрое решение ряда проблем у уже существующих решений. К сожалению, ради этих решений он пожертвовал многими функциями, которые будут актуальны для большинства пользователей. Именно поэтому он не может заменить IPsec или OpenVPN.
Для того, чтобы WireGuard стал конкурентным, ему нужно добавить хотя бы настройку IP-адреса и конфигурацию маршрутизации и DNS. Очевидно, что именно для этого нужны зашифрованные каналы.
Безопасность — мой главный приоритет, и сейчас у меня нет оснований полагать, что IKE или TLS как-то скомпрометированы или поломаны. Современное шифрование поддерживается в них обоих, и они были проверены десятилетиями эксплуатации. Если что-то новее не значит, что это что-то — лучше.
Функциональная совместимость крайне важна, когда вы связываетесь с третьими лицами, станции которых вы не контролируете. IPsec де-факто является стандартом и поддерживается практически повсеместно. И он работает. И как бы это не выглядело, в теории, WireGuard в будущем может быть несовместим даже с разными версиями самого себя.
Любая криптографическая защита рано или поздно взламывается и, соответственно, должна быть заменена или обновлена.
Отрицание всех этих фактов и слепое желание использовать WireGuard для подключения вашего iPhone к домашней рабочей станции — это просто мастер-класс по засовыванию головы в песок.
