Разбираем VLESS

Определение

VLESS - это легкий транспортный протокол, без сохранения состояния, который разделен на входящую и исходящую части и может использоваться в качестве моста между клиентом и сервером Xray.

В отличие от VMess, VLESS не зависит от системного времени.

Метод аутентификации основан на UUID

Запрос и ответ

VLESS имеет следующую структуру запроса

1 байт	16 байт	1 байт	M байт	1 байт	2 байта	1 байт	S байт	X байт
Версия протокола	Соответствующий UUID	Длина дополнительной информации M	Дополнительная информация в ProtoBuf	Инструкции	Порт	Тип адреса	Адресс	Запрос

VLESS имеет следующую структуру ответа

1 байт	1 байт	N байт	Y байт
Версия протокола, соответствующая запросу	Длина дополнительной информации N	Дополнительная информация в ProtoBuf	Ответ

VLESS поддерживает множество режимов передачи: TCP, gPRC, H2, quic, WebSocket, mKCP. Но так как XTLS, о котором мы поговорим немногим позже, в настоящее время поддерживает только TCP, то для нас,TCP, является единственно рекомендуемым, в настоящее время, режимом передачи

Кроме того, XTLS в настоящее время поддерживает только три метода передачи: TCP, mKCP и DomainSocket. В настоящее время у VLESS нет встроенного шифрования, поэтому его необходимо использовать совместно с TLS.

REALITY

Проект REALITY, представляет собой новаторскую разработку, являющуюся развитием и улучшением существующих технологий TLS (Transport Layer Security).

Вот ключевые аспекты, которые помогут понять, как работает REALITY:

Устойчивость к Атакам на Цепочку Сертификатов: Одна из ключевых особенностей REALITY - это улучшенная устойчивость к атакам, связанным с цепочкой сертификатов. В традиционном TLS, безопасность соединения во многом зависит от доверия к центрам сертификации (CA), которые выдают сертификаты. Атаки на цепочку сертификатов могут происходить, если злоумышленник может скомпрометировать или подделать сертификат, выданный CA. REALITY стремится уменьшить эту уязвимость, предоставляя дополнительные механизмы безопасности, которые делают такие атаки менее эффективными.
Сокрытие Отпечатков TLS: Отпечатки TLS - это уникальные характеристики, которые могут быть использованы для идентификации и блокировки определенных типов зашифрованного трафика. В странах с жесткой интернет-цензурой, например, правительства могут использовать отпечатки TLS для обнаружения и блокировки VPN-трафика. REALITY разрабатывается с целью минимизации этих отпечатков, делая трафик менее узнаваемым и, следовательно, более устойчивым к цензуре и блокировкам.
Прямая Секретность: Этот принцип безопасности гарантирует, что даже если ключи шифрования будут скомпрометированы в будущем, злоумышленники не смогут расшифровать прошлые сессии. REALITY поддерживает прямую секретность, обеспечивая, что каждая сессия зашифрована уникальным сеансовым ключом.
Reality позволяет указывать на чужие сайты без необходимости покупки собственного домена или настройки TLS-сервера, что делает его более удобным для использования и позволяет представлять полностью реальный TLS с определенным SNI посреднику.
Совместимость с Существующими Протоколами: REALITY разработан так, чтобы быть совместимым с существующими протоколами, это означает, что он может быть интегрирован в существующие системы без необходимости кардинальных изменений, но это не рекомендуется из-за существующих и легко распознаваемых особенностей TLS в TLS.
Прозрачность для Пользователей и Серверов: Протокол предназначен для работы таким образом, чтобы быть прозрачным как для клиентов, так и для серверов, что облегчает его внедрение и использование.
Поддержка Современных Стандартов: REALITY поддерживает современные стандарты безопасности и шифрования, обеспечивая высокий уровень защиты данных.
Гибкость и Настройка: Протокол предлагает различные опции настройки для удовлетворения специфических требований безопасности и производительности.

XTLS

Основная концепция XTLS:

Основная логика XTLS заключается в использовании настоящего TLS для маскировки прокси-трафика среди самого обычного интернет-трафика. Для обычного TLS прокси-протокола (например, оригинального Trojan), клиент прокси пользователя устанавливает настоящее TLS соединение с прокси-сервером, и через этот зашифрованный туннель приложение (например, браузер) устанавливает еще одно TLS соединение с целевым сервером (например, Google). В этот момент браузер и сервер Google обеспечивают end-to-end шифрование, и никто (включая наш прокси) не может расшифровать или подделать отправляемую информацию. Это и есть так называемое e2e.”

Вот краткая схема: Браузер ---- Прокси-клиент ==== Прокси-сервер ---- Google

Когда прокси-данные проходят через цензора, они фактически шифруются дважды. Однако, в этом процессе, 99% трафика на самом деле не требует дополнительного шифрования. Поскольку данные, зашифрованные с помощью TLS 1.3, внешне выглядят абсолютно одинаково, цензор не может их различить.

Таким образом, логика прокси должна быть следующей:

Установить настоящее TLS-соединение.
Внутри зашифрованного туннеля отслеживать коммуникацию между браузером и Google, определяя, является ли текущее соединение TLS 1.3.
Если нет, то использовать обычный метод TLS-прокси, продолжая использовать зашифрованный туннель.
Если да, то дождаться начала передачи зашифрованных данных обеими сторонами, а клиент прокси вставляет UUID в первый внутренний зашифрованный пакет, сигнализируя серверу прокси: мы готовы к ‘голому’ соединению!
Начиная со второго внутреннего зашифрованного пакета, XTLS больше не выполняет никаких операций с данными, а просто копирует их. Это и есть xtls-rprx-vision.

Мы можем заметить, что:

Внешний TLS, инициированный прокси, является настоящим, поэтому цензор не может его взломать.
‘Голый’ трафик на стороне прокси просто копируется без изменений. Если цензор попытается вмешаться, он получит стандартный ответ от браузера и сервера Google, который не будет отличаться от обычного доступа.
Сигналом для ‘голого’ соединения служит UUID, который является приватной информацией прокси, чтобы избежать уязвимостей, подобных тем, что были в Go, связанных с использованием кодовых характеристик для определения части”

Почти совершенно

С 3 октября, в Китае, началось массовое распознавание и блокирование TLS-прокси. Из некоторых обсуждений и внутренней информации мы узнали, что цензоры использовали огромные ресурсы и методы машинного обучения. Как известно, сильная сторона машинного обучения - извлечение статистических характеристик из больших объемов данных.

Одним из важных недостатков обычного TLS-прокси является ‘шифрование в шифровании’. Как обсуждалось выше, хотя внешний вид зашифрованных пакетов неотличим для цензора, неизбежным является увеличение заголовка каждого пакета с каждым уровнем шифрования. Это увеличение может быть незначительным, но для маленьких данных (например, пакетов ответов) оно может быть более заметным, и некоторые пакеты могут превышать ограничения MTU сетевого уровня. Самое важное - каждый пакет увеличивается на одинаковую длину, что может создавать определенные статистические характеристики.

XTLS изначально был разработан , чтобы уменьшить дополнительное шифрование. Новый потоковый контроль Vision был введен, потому что XTLS обладает уникальной способностью противостоять цензуре. Можно сказать, что когда передаются данные TLS 1.3, 99% пакетов XTLS имеют почти идеальные характеристики трафика, потому что это оригинальные данные, не обработанные прокси.

TLS в TLS

Почему мы говорим, что 99% пакетов являются оригинальными данными? Что представляют собой оставшиеся 1%? Нам нужно исследовать, что происходит в типичном прокси при встрече с трафиком TLS 1.3 в первых нескольких пакетах.

Наглядно, после установления зашифрованного канала:

Первый пакет: Прокси-клиент -> Прокси-сервер: “Привет, цель этого прокси-сессии - Google, вот мой UUID.”
Второй пакет: Прокси-клиент <- Прокси-сервер: “Привет, получил твой запрос на прокси, начинай отправлять данные.”
Третий пакет: Браузер -> Прокси-клиент -> Прокси-сервер -> Google: “Привет, Google, я собираюсь начать с тобой зашифрованное общение, вот мои поддерживаемые методы шифрования…” (Этот пакет также называется TLS Client Hello).
Четвертый пакет: Браузер <- Прокси-клиент <- Прокси-сервер <- Google: “Привет, пользователь, вот сертификат Google, мы будем использовать шифрование TLS_AES_128_GCM_SHA256, давай начнем зашифрованное общение!” (Этот пакет также называется TLS Server Hello).
Пятый пакет: Браузер -> Прокси-клиент -> Прокси-сервер -> Google: “Понял, давай начнем зашифрованное общение!”

Как вы знаете, протоколы прокси разнообразны, но основа одна и та же: если пользователь использует любое TLS-соединение, необходимо выполнить вышеупомянутый процесс рукопожатия. Как упоминалось ранее, внешнее TLS-шифрование можно считать абсолютно безопасным, но для цензора, помимо взлома информации, есть возможность использовать некоторые дополнительные данные для идентификации этих пяти пакетов.

Это ключевые моменты обнаружения TLS в TLS.”

Пять пакетов

Самой очевидной характеристикой этих пяти пакетов является их длина. В частности:

Первый пакет: очень короткий, единственная переменная - целевой адрес.
Второй пакет: очень короткий, почти фиксированный.
Третий пакет: короткий, с небольшими изменениями, почти единственная переменная - целевой SNI.
Четвертый пакет: длинный, с большими изменениями.
Пятый пакет: очень короткий, с небольшими изменениями.

Можно интуитивно почувствовать, что характеристики длины этих пакетов довольно очевидны. В Vision подход к решению этой проблемы также прост: мы увеличиваем длину каждого короткого пакета до диапазона от 900 до 1400. Обратите внимание, что этот метод отличается от традиционного случайного заполнения; мы не просто добавляем заполнение ко всем пакетам, а основываясь на нашем анализе внутреннего трафика, целенаправленно заполняем характерные пакеты TLS-рукопожатия.

Другой менее заметной характеристикой является временная последовательность. Из-за дизайна TLS-рукопожатия можно заметить, что порядок первых нескольких пакетов фиксирован. То есть, после отправки браузером TLS Client Hello, он должен дождаться ответа Google с TLS Server Hello, после чего браузер должен отправить сообщение “Понял, давай начнем зашифрованное общение!”, чтобы диалог мог продолжаться.

Если обозначить пакеты, идущие от пользователя к серверу, как C, а в обратном направлении - как S, может ли цензор определить TLS в TLS соединение по временной последовательности данных CSCSC и их временным интервалам? пока недостаточно оснований для таких выводов, и Vision не обрабатывает этот аспект.”

Часто задаваемые вопросы

Длина заполнения в Vision зафиксирована, не создает ли это статистические характеристики?

В первую очередь, в концепции сетевой безопасности нет абсолютной безопасности, теоретически любое шифрование можно взломать силой, это лишь вопрос вычислительных ресурсов. Как разработчики безопасных протоколов, наша задача - повысить сложность взлома и обнаружения до уровня, недостижимого для цензоров. Насколько высок этот уровень? Это мы узнаем в ходе борьбы.

Возвращаясь к известным нам данным, длина пакетов рукопожатия TLS 1.2 и 1.3 довольно стабильна. Несколько ключевых пакетов, посещающих основные сайты (например, Google), можно считать фиксированной длины. Если сравнить текущую длину больших пакетов Vision с длиной незаполненных рукопожатий, сложность обнаружения, вероятно, увеличится на порядок.

Кроме того, в некоторых утечках обсуждений упоминалось, что машинное обучение может распознавать случайное заполнение менее 40%. Это косвенно подтверждает наличие предела распознавания у машинного обучения.”

Почему новый потоковый контроль назван Vision?

Ответ: Мы считаем, что Vision отражает первоначальную концепцию дизайна RPRX. XTLS первоначально разрабатывался в процессе исследования и был ограничен тогдашними условиями разработки, что делало некоторые аспекты слишком сложными. Таким образом, Vision представляет идеальное состояние и будущее направление XTLS. RPRX говорит: “Flow.. Какую проблему он решает? Он влияет на макроскопические временные характеристики трафика, а не на микроскопические, которые являются задачей шифрования. Временные характеристики трафика могут быть вызваны протоколом, например, Socks5 over TLS с рукопожатием Socks5, разные характеристики на уровне TLS означают разные протоколы для наблюдателя, таким образом, бесконечные планировщики (Schedulers) эквивалентны бесконечному количеству протоколов (перераспределение объема данных для каждой отправки и т.д.)“

Этот новый потоковый контроль так хорош, рекомендуете ли вы всем использовать его для обхода блокировок?

Ответ: Как говорят другие разработчики, для текущих цензоров опасно класть все яйца в одну корзину. Поэтому мы рекомендуем активно использовать особенности каждого инструмента и разнообразить ваш набор инструментов.”