顶呱呱

解释的相当通俗，让我这种TLS小白也能看的津津有味。
很棒的文章，感谢分享。

致敬各位开发者、维护者以及RPRX，你们的无私付出让我更加了解世界！

非常棒，尤其是当我读到“翻墙技术战争”的时候，这四个字完全可以用“较量”“切磋”这么LOW的！这充分反映了我们所处的时代境况。
还有就是“国密”时，完全赞同！
正是使用了这个项目，使我在个人领域学习到了更多国外高级的知识。“谢谢”是我这2年来最想对你们说的话。

非常感谢！非常感谢！

Никогда не думал, что наше технологическое дерево будет выглядеть так

Hi,
thanks for your great effort.
I've configured xtls-vision on my server and its working soo good.
I have 2 Questions:

1. Is it possible to hide xtls-vision behind the nginx and a camo website? kinda like wulabing's vless-tls-ws nginx front.
2. Is it possible to make it work behind the CloudFlare' CDN?

TNX

很好，深入浅出，完全不懂计算机网络这些东西都能看明白。接下来就是按图索骥，摸索，学习了。

燃！！！！

如果开启了MUX.cool并且加上vision的填充，是不是就更加没有容易分辨的特征了？

大流量协议似乎只有下载类的Torrent模式

远程桌面也支持TLS1.3，套一个Reality可行吗 @yuhan6665

XTLS

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

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

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

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

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

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

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

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

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

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

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

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

TLS в TLS

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

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

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

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

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

Пять пакетов

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

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

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

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

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

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

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

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

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

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

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

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

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

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