Большинство VPN-провайдеров для построения сервисов использует стандартные решения вроде OpenVPN и IKEv2. Однако малая их часть выбирает другой путь и разрабатывает собственные протоколы — одним из них стал Lightway. В статье обсуждаем его возможности, достоинства, недостатки и безопасность.
Что «под капотом»
Lightway разработал VPN-провайдер ExpressVPN, который в начале августа передал исходники в open source под лицензией GPLv2. По словам авторов, они хотели сделать легкий и производительный протокол, поэтому использовали язык программирования C и реализовали только необходимые функции безопасности — объем кодовой базы составил примерно две тысячи строк. Lightway совместим с Linux, Windows, macOS, мобильными платформами и маршрутизаторами (Netgear, Linksys).
В основе нового протокола лежит криптографическая библиотека wolfSSL. Она соответствует стандарту компьютерной безопасности FIPS 140-2, который разрабатывает институт NIST в США, и уже нашла применение в «боевых» криптографических задачах. Например, её используют разработчики IoT-систем и производители GPRS-терминалов. Первые шифруют данные в устройствах умного дома, а вторые — реализуют интерфейсы типа machine-to-machine (M2M).
При передаче данных Lightway использует UDP, а для установления защищенного канала связи — DTLS. В то же время протокол может работать поверх TCP и TLS 1.3. Для обмена ключами разработчики использовали механизм Диффи-Хеллмана на эллиптических кривых (ECDH). Обмен происходит каждые 15 минут или при переключении сети. Если по какой-то причине использовать ECDH невозможно, система обращается к классическому протоколу Диффи — Хеллмана (DH).
Lightway не привязывает ключи к внутренним IP-адресам (как это делают некоторые VPN-протоколы), и пользователи получают новый адрес при каждом переподключении — в теории такой подход повышает приватность.
Перспективы и критика
Протокол обладает высокой производительностью, и по оценкам разработчиков, в 2,5 раза быстрее конкурентов — OpenVPN, IKEv2, PPTP и SSTP. Но справедливости ради стоит отметить, что авторы не раскрыли критерии и условия тестирования. В связи с этим к указанному показателю стоит относиться с долей скептицизма.
В то же время разработчики говорят, что кодовая база протокола меньше, чем у других популярных решений, и её проще проверять на ошибки. Хотя один из резидентов Hacker News в тематическом треде отметил некоторые непостоянства в структурировании кода, что немного мешает оценить его качество.
Однако в начале лета код прошел независимый аудит безопасности — его провели специалисты из Cure53, оценившие реализацию NTP-протокола NTPsec и свободный IMAP-сервер Dovecot. Проект получил высокий балл, хотя эксперты обнаружили уязвимости (стр.3), открывающие возможности для DoS [их сразу устранили]. Ряд недостатков связали со сторонними библиотеками и компонентами — например, была уязвимость CVE-2020-3336 в WolfSSL, позволяющая злоумышленникам проводить MITM-атаки [в середине июня разработчики выпустили для неё патч].
Ряд ИБ-специалистов среди потенциальных недостатков также выделяет отсутствие обфускации. Так, интернет-провайдер, в сети которого работает Lightway, может понять, что клиент использует VPN-подключение. В любом случае это довольно молодой протокол, поэтому может пройти еще какое-то время, прежде чем недостатки устранят. Разработчики приглашают поучаствовать всех желающих — свои предложения и «пул-реквесты» можно оставлять на GitHub.
Кто еще
К относительно новым VPN-протоколам можно отнести WireGuard. Это — VPN-туннель, разработка которого идет с 2016 года. Он использует алгоритмы ChaCha20 и Poly1305, а его пропускная способность в четыре раза выше, чем у OpenVPN.
В начале прошлого года его даже включили в ядро Linux. Однако авторы отмечают, что WireGuard — экспериментальный протокол и работа с ним несет определенные риски. Например, он сохраняет подключённые IP-адреса на сервере, что отрицательно влияет на приватность. Потенциальным проблемам, связанным с ним, даже была посвящена отдельная большая статья на Хабре.
Хотя сегодня многие VPN-провайдеры нашли способы борьбы с этими недостатками и постепенно внедряют WireGuard в свои сервисы. Возможно, в будущем он и Lightway найдут более широкое применение, если на их развитии не отразится желание регуляторов ввести ограничения на работу с end-to-end шифрованием.
Почитать о протоколах:
Протокол IPFS — будущее интернета или еще одна «проходная» технология
Почему шифрование DNS не всегда эффективно — обсуждаем мнения
«Одной канарейки мало»: у VPN-сервисов все чаще запрашивают ПД
И работе интернет-провайдеров:
Комментарии (38)
AndrChm
28.08.2021 23:53+4Если по какой-то причине использовать ECDH невозможно, система обращается к классическому протоколу Диффи — Хеллмана (DH).
Вот интересно, а что это за причины такие могут быть? Тем более, как я понял, борьба шла за компактность кода. Боролись, боролись, а потом вдруг, бац, и изменили принципам. Подозрительно как-то…
Revertis
29.08.2021 12:53Если вдруг DPI перегружен, и не хочет тратить такты на ECDH, то махнёт клиентам, что ECDH не получается, и они переключатся на DH. Удобная фитча ;)
AndrChm
29.08.2021 13:38+3Приблизительно так и подумал. Только DPI тут скорее всего ни при чём. Если заранее в DH предусмотрен низкий уровень криптостойкости по сравнению с ECDH, то переключение с более криптостойкого на менее криптостойкий протокол происходит просто по звонку товарища майора. Я бы не стал пользоваться таким VPN-сервисом и другим не посоветовал. Замечу, что когда речь идёт о вопросах безопасности, параноидальный подход вполне оправдан.
Кстати, это может быть связано с экспортными ограничениями на криптографию. Например, вариант с DH, который гарантирует 40-битный уровень криптостойкости, подключается в том случае, когда софт экспортируется в страны, на которые не распространяется юрисдикция страны-регулятора. Обычно этим такими штуками занимаются США.
dakuan
19.09.2021 16:26Ну например, если wolfSSL на одной из сторон собран без поддержки ECC. Redhat вон сколько лет не хотели ECC добавлять в свои дистры из-за патентных ограничений.
AndrChm
19.09.2021 18:06WolfSSL использует библиотеку wolfCrypt, которая включает ECC в ряду прочего. Поэтому приведённый пример некорректен. А можете привести пример чего-то такого криптографического и достаточно распространённого, что не включает реализацию примитивов ECC? Просто даже интересно…
dakuan
20.09.2021 03:34WolfSSL использует библиотеку wolfCrypt, которая включает ECC в ряду прочего. Поэтому приведённый пример некорректен.
При чем тут что она использует? Поддержку ECC в wolfSSL можно отключить при сборке.
А можете привести пример чего-то такого криптографического и достаточно распространённого
Пример я уже привел: долгое время в RHEL/CentOS была отключена поддержка ECC, включили ее только в CentOS 6.5 или 7, не помню точно. Кто-то может руководствоваться анологичными соображениями. Или, возможно, кто-то захочет создать собственную реализацию протокола, но не может или не хочет по каким-то причинам использовать ECC. Если вас беспокоит компактность кода, то на нее это влияния практически не окажет - просто при конфигурации контекста передаете один дополнительный cipher suite в конце списка и все.
AndrChm
20.09.2021 14:44Выбор ЕСС для реализации криптографических примитивов – не дань моде. За этим стоят вполне рациональные соображения. Прочитать популярное объяснение про ECDLP и DLP можно здесь habr.com/ru/post/564596 в подкате. Если говорить о практических последствиях использования ECC, то это выражается в существенной экономии долговременной памяти, предназначенной для хранения общедоступных ключей. В первую очередь это касается PKI (Вы понимаете, что это всё про бабки, попросту говоря?). Выигрыш достигает порядка и более в зависимости от требований криптостойкости. Так что ECC – это даже не стандарт де-юро, но стандарт де-факто. Странно предполагать, что разработчики при реализации криптопримитивов вдруг начнут отказывать от лучшего в пользу худшего. Так что ваши аргументы выглядят несерьёзно. В духе: А вдруг кто-то что-то не так сделает? Вот уж мы подстрахуемся. Что касается компактности кода, то это тоже не так. Арифметика точек в подгруппе простого порядка группы точек эллиптической кривой принципиально отличается от арифметики элементов подгруппы простого порядка мультипликативной группы конечного поля. Имеют совершенно различную реализация. Значит, если у нас есть и то, и другое, то это неизбежно приведёт к разрастанию кода. Это объективно. Без всяких малозначащих слов «один дополнительный cipher suite в конце списка и всё.»
dakuan
20.09.2021 19:49Так что ECC – это даже не стандарт де-юро, но стандарт де-факто.
Может быть, в этом и проблема?
Странно предполагать, что разработчики при реализации криптопримитивов вдруг начнут отказывать от лучшего в пользу худшего. Так что ваши аргументы выглядят несерьёзно.
Почему странно? В TLS 1.3 точно так же есть поддержка и ECDHE и DHE.
В первую очередь это касается PKI (Вы понимаете, что это всё про бабки, попросту говоря?).
Вот это поясните, пожалуйста. В контексте LIghtway о каких долговременных ключах идет речь и каким образом отказ от DHE позволит экономить долговременную память.
Что касается компактности кода, то это тоже не так. Арифметика точек в подгруппе простого порядка группы точек эллиптической кривой принципиально отличается от арифметики элементов подгруппы простого порядка мультипликативной группы конечного поля. Имеют совершенно различную реализация. Значит, если у нас есть и то, и другое, то это неизбежно приведёт к разрастанию кода. Это объективно.
Мы сейчас о каком коде говорим? К разрастанию кода Lightway это не приведет, т.к. его авторам не нужно ничего реализовывать самим - они используют стороннюю библиотеку для этого. Все влияние на размер кодовой базы Lightway сводится к тому, что вместо
wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-RSA-CHACHA20-POLY1305");они пишут
wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305");Напомню, что компактность кода речь пошла вот из-за этого вашего поста:
Тем более, как я понял, борьба шла за компактность кода. Боролись, боролись, а потом вдруг, бац, и изменили принципам. Подозрительно как-то…
AndrChm
20.09.2021 20:02Вот от это поясните, пожалуйста. В контексте LIghtway о каких долговременных ключах идет речь и каким образом отказ от DHE позволит экономить долговременную память.
Ну, давайте с самого начала. Что Вы понимаете под lightway? Может это lightweight? В смысле «облегчённая криптография» (lightweight cryptography)? Если так, то почему эта тема вдруг нарисовалась? Следующий вопрос. Вы серьёзно полагаете, что асимметричная криптография работает без сертификатов общедоступных ключей? Надо всё выяснять по-порядку. А то Вы начинаете перескакивать с одной темы на другую.
dakuan
20.09.2021 20:36Что Вы понимаете под lightway?
Lightway - это название протокола, который мы сейчас обсуждаем)
Вы серьёзно полагаете, что асимметричная криптография работает без сертификатов общедоступных ключей?
Нет, не полагаю. Но при условии, что они используют RSA, то отказ от DHE в пользу ECDHE никак не повлияет PKI.
AndrChm
20.09.2021 20:46Если RSA используется в режиме ЭЦП, то тогда проигрыш по разрядности общедоступного ключа при фиксированном уровне криптостойкости будет по сравнению с ECDSA, например, или по сравнению с любым другим алгоритмом ЭЦП на основе арифметики точек эллиптической кривой. Вообще, RSA в настоящий момент не соответствует трендам современной криптографии. Проблема не только с издержками при хранении сертификатов общедоступных ключей, но и с вычислительными трудозатратами на формирование/проверку ЭЦП и зашифрование/расшифрование. Хотя этот аспект также связан с разрядностью ключей.
AndrChm
20.09.2021 20:09…т.к. его авторам не нужно ничего реализовывать самим - они используют стороннюю библиотеку для этого.
А в сторонней библиотеке не должно быть реализации всей байды, которая характерна для ECC, и всего стального для реализации примитивов на основе арифметики элементов конечного поля? Программный код для всего этого откуда возьмётся? Если я подключаю различные реализации, то это очевидно сказывается на размере результирующего кода, как на стороне клиента, так и на стороне сервера.
dakuan
20.09.2021 20:44Если я подключаю различные реализации, то это очевидно сказывается на размере результирующего кода, как на стороне клиента, так и на стороне сервера.
Необязательно. Можно использовать не wolfSSL, а системный OpenSSL, например.
AndrChm
20.09.2021 21:00А какая разница, какой библиотекой пользоваться?
Если имеется два различных варианта, то для них так или иначе должен быть программный код и для клиента и для сервера. Вот и вопрос: А зачем это дублирование? Тем более, что оба варианта обеспечивают одну и ту же функциональность. Только вот за один из вариантов надо либо больше платить, либо возникают сомнения в его криптостойкости.
dakuan
20.09.2021 21:41Только вот за один из вариантов надо либо больше платить, либо возникают сомнения в его криптостойкости.
Это почему? При правильном использовании DHE обеспечивает адекватную безопасность.
AndrChm
20.09.2021 21:49Вы меня не слышите. Посмотрите вот этот документ www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014
В нём совершенно ясно указано, как различаются ключи для ECDH и DH для уровня криптостойкости 80 бит, например.
dakuan
20.09.2021 22:53Поэтому и надо использовать адекватные параметры. Просто обмен будет занимать больше времени, но обычно это не так уж страшно.
AndrChm
20.09.2021 22:55Мне эта логика не понятна. Зачем делать криво и некрасиво, когда можно сделать ровно и красиво? Всю подноготную я уже изложил.
AndrChm
20.09.2021 20:35…каким образом отказ от DHE позволит экономить долговременную память.</span>
Очень просто. Если использовать, например, ECDH при некотором заданном уровне криптостойкости, то разрядность (длина в битах) общедоступного ключа для ECDH будет на порядок короче, чем разрядность общедоступного ключа для DH при том же уровне криптостойкости. Если Вы считаете, что сертификаты для общедоступных ключей в случае ECDH/DH не нужны, то это означает, что Вы просто не понимаете основ криптоанализа. Такое название атаки как MiTM вам ничего не говорит? Что касается выпуска и обслуживание сертификатов, то за это надо платить. Обычно, если разрядность общедоступного ключа превышает некоторый лимит, то подключается дорогой тариф. Дальше всё регулирует рынок. Если за тот же самый уровень криптостойкости мне необходимо платить больше, то я просто откажусь от такого продукта. Если разрядность не превышает лимита, то возникает вопрос о криптостойкости. Если он низкий, то я опять же откажусь от продукта, но уже по другой причине. Это простые соображения. Обычно их все понимают.
dakuan
20.09.2021 21:13Если Вы считаете, что сертификаты для общедоступных ключей в случае ECDH/DH не нужны, то это означает, что Вы просто не понимаете основ криптоанализа. Такое название атаки как MiTM вам ничего не говорит?
Сбавьте тон, пожалуйста. Подобные наезды - это не слишком-то профессионально. Я прекрасно понимаю, о чем говорю.
У нас есть конкретный протокол, который использует (EC)DHE для обмена ключами и RSA для подписи в обоих случаях.
AndrChm
20.09.2021 21:33Я выше уже написал, почему RSA проигрывает любому алгоритму ECC. Если хотите точнее, то есть теоретические результаты, которые показывают, что проблема факторизации (FP), которая лежит в основе криптостойкости RSA, связана с DLP. Из этого факта в частности следует, что для FP существуют алгоритмы факторизации субэкспоненциальной трудоёмкости. Соответственно при заданном уровне криптостойкости, для компенсации уязвимости по причине существования алгоритмов такой трудоёмкости, приходится «раздувать» разрядность RSA-ключей, как секретных, так и общедоступных. Со всеми вытекающими последствиями.
dakuan
20.09.2021 21:50Но если вы выкинете DHE из Lightway, то от RSA и необходимости хранить ключи все равно не избавитесь.
AndrChm
20.09.2021 22:04А в чём проблема? Это как раз к вопросу о преимуществе ЕСС. Просто замените RSA в режиме ЭЦП на любой другой алгоритм ЭЦП на основе точек эллиптической кривой. Это может быть что угодно: ECDSA, наш российский национальный стандарт и пр. На любую ЭЦП из ECC. Всегда получите выигрыш. В этом же смысл. Мы же ведь на RSA не молимся? Так что надо просто уметь правильно пользоваться этими вещами.
dakuan
20.09.2021 22:34Это уже не ко мне вопрос. Я тоже не могу понять, почему разработчики предусмотрели возможность использовать DHE вместо ECDHE, но не предусмотрели возможности использовать, например, ECDSA. Но вот почему-то решили использовать только RSA. Могу предположить, что хотели избавить пользователей от необходимости получать новые ключи. Либо проблема в их инфраструктуре. Это все же изначально коммерческий продукт, который разрабатывался под их внутренние требования, а уже потом ушел в open source. Поэтому и подход к разработке немного другой.
AndrChm
20.09.2021 22:47Могу предположить, что хотели избавить пользователей от необходимости получать новые ключи.
Это как? То есть в случае RSA получать новые ключи не надо, а в случае ECDSA – надо? И вообще, что значит «получать новые ключи»? Если речь идёт о сертификате общедоступного ключа, то тут единый подход, который в общем случае не зависит от алгоритма ЭЦП. Всё регулируется положениями сертификационной политики/практики. Могут быть отдельные исключения, например в случае lightweight cryptography (LC). Но в основном это касается жизненного цикла сертификата. Обычно в случае LC он короче. Так что не понятно, что Вы имеете в виду.
dakuan
20.09.2021 23:07Это как? То есть в случае RSA получать новые ключи не надо, а в случае ECDSA – надо?
Это всего лишь предположение. Скорее всего до создания этого протокола, они использовали какое-то другое решение. Возможно, OpenVPN или ikev2, поэтому у существующих пользователей на руках уже есть: сертификат CA, сертификат самого пользователя и соответствующий приватный ключ (RSA). Поэтому для перехода на новый протокол, ему нужно только скачать новый клиент. И самому провайдеру не нужно обновлять PKI.
AndrChm
20.09.2021 23:13Вот зачем тут фантазировать. Так можно далеко зайти. Резюмирую. К продукту много различных вопросов. Некоторые подходы подозрительны. Поскольку речь идёт о безопасности, то разумно следовать параноидальной стратегии и просто не пользоваться такими продуктами.
dakuan
20.09.2021 23:24Поскольку речь идёт о безопасности, то разумно следовать параноидальной стратегии и просто не пользоваться такими продуктами.
Это просто наиболее правдоподобное объяснение, которое я могу придумать. К протоколу есть вопросы, тут согласен. Но если вы подозреваете, что VPN-провайдер активно сотрудничает со спецслужбами, то тут даже идеально спроектированный протокол не поможет.
AndrChm
21.09.2021 00:00Я всегда подозреваю. Только в одном случае мне не дают прямого повода, в другом – этих поводов вагон и маленькая тележка. Вот и весь сказ.
AndrChm
20.09.2021 22:13Кстати, если мне в каком-либо продукте безальтернативно навязываю RSA, то это точно не в пользу этого продукта. Специалист понимает, к чему это в итоге может привести (см. вышеизложенные аргументы и рассуждения).
AndrChm
20.09.2021 23:20В профессиональной литературе протокол Diffie-Hellman в различных его реинкарнациях называется key-agreement protocol. По-русски это будет «протокол согласования ключа». И это действительно так. Ничего там не передаётся, кроме сеансовых общедоступных ключей, заверенных ЭЦП, а совместными действиями вырабатывается (согласовывается) одноразовый сеансовый секретный ключ.
dakuan
20.09.2021 23:26А я разве где-то утверждал обратное?
AndrChm
20.09.2021 23:50«У нас есть конкретный протокол, который использует (EC)DHE для обмена ключами…»
dakuan
21.09.2021 00:34Не могу понять, что тут вам не нравится. Перевод на русский язык термина "Diffie-Hellman key exchange" что ли?
AndrChm
21.09.2021 00:24Есть ещё key-transport protocol. Например, так называемый «цифровой конверт». Вот в нём секретный ключ действительно передаётся. Отличается от Diffie-Hellman.
edo1h
честно говоря, я не понял где тут киллер-фича.
динамические внутренние адреса клиентов? в openvpn оно есть, в wg, думаю, не так сложно прикрутить.
производительность? что-то у меня есть сомнения в превосходстве над ipsec и wg. плюс для ipsec полно аппаратных решений.
2k LoC? ну это жирный плюс, конечно, но на киллер-фичу, думаю, не тянет.
edo1h
да, в сравнении с wg в качестве основного преимущества рассматривается именно это. ну и как дополнительные — возможность работы через tcp и потенциальная возможность писать плагины для маскировки трафика.
https://lightway.com/docs/lightway-core/1.0.0/faq.html