Привет. Вдохновился этим тредом. Вижу следующие варианты.
- VLESS + VISION + REALITY под чужой сайт.
- VLESS + VISION + REALITY под свой сайт.
- VLESS + VISION + TLS + FALLBACK под свой сайт.
Первый вариант выглядит хорошо, но правильно ли я понял, что блокиратор может запросить все IP сайта, под который идёт маскировка, и заблокировать ваш IP, так как его не будет в этом списке? Почему в Китае так не делают? или делают? В чём заключаются издержки таких блокировок?
Между вторым и третьим вариантом вроде бы нет большой разницы? Я только заметил, что во втором варианте SNI клиента и сервера должны совпадать (хотя вбить можно что угодно; необязательно даже домен покупать свой).
Если вы пользуетесь третьим вариантом, можно ли настроить так, чтобы одно подключение умело принимать соединения с разными SNI от клиента? Может пригодиться, если выбранный SNI улетит в блок. Если можно, то вместо второго варианта, я бы выбрал третий.
Ещё есть такие мысли.
- Если маскироваться под чужой сайт, то надо нагнать туда трафика, иначе очень странно выглядит сервер майкрософта, к которому из всей необъятной подключается один Вася Пупкин.
- Если маскироваться под свой сайт, то надо строго ограничивать трафик и локации, с которых к нему подключаются.
Как вы думаете?
Каким образом? Я так и представляю что какая-нибудь условная локальная газета определённый страны, Швеция например должна будет Китайцам все свои ip выдать. Это бред же, основной траффик DDOS атак это как раз Китай и США,а тут прям в наглую просить будут ип сервера (с подписью точно не для ддос атак).
А если под большие кто-то маскироваться будет, то будет достаточно сменить sni на что-то поменьше
Делают, если трафик с vps идёт из Китая обратно в Китай = бан ип или бан порта.
То что цензору понадобиться или забанить ип сервера который маскируется, или забанить домен под который маскируються
У них есть “жёсткая” политика блокировок, это когда всё что plain text и понятный поток байт не баниться, а всё остольное умирает, такое в основном если какая-то тряска в стране происходит.
Есть, я бы даже сказал титаническая. Прочитайте про TLS-in-TLS. На гитхабе у создателей xray вообще тулза лежит для определения такого трафика, в Reality такого не происходит. GitHub - XTLS/Trojan-killer: Detect TLS in TLS.
На 99% уверен что нет, к сожалению
Я думаю вряд ли через ТСПУ кол-во трафика (в плане людей) регестрируют, а условный CF фиг РКН чё выдадит по сайту васи пупкина. Если маскироваться, то под средний сайт, желательно в сети вашего же хостера. Ведь тупо будет смотреться как мелкомягкие хостяться у хостера которого знает и пользуються 2 с половиной человека (от общего масштаба).
А толк? Active probing’ом РКН будет с ру ип заниматься. А вот АНБ твой сервак не нужен. Ну на крайний случай АНБ не заблокирует твой сервер в отлчии от РКН. А забанив все кроме ру ип ты лишаешся любых обновлений системы, пакетов и т.д с т.п
Короче бесполезное занятие как по мне
Я бы выбрал или 1 или 2, 2 лучше, но стоит того
“Reality такого не происходит.” Вы путаете rprx-vision и reality.
Благодарю за ответ.
Для крупного сайта можно же проверить, что IP сервера входит в выделенные диапазоны IP автономных систем компании, или нет?
Так я же написал про VISION. Его можно и без REALITY использовать.
Чем второй вариант лучше, кроме независимости от доступности чужого сайта и от задержи до него? В случае белых списков доменов первый вариант хотя бы можно будет заставить работать.
Можно добавить вариант VLESS + HTTP2 + REALITY + MULTIPLEX.
Это будет эффективнее, я считаю. С использованием sing-box к тому-же. Хоть свой сайт, хоть чужой. TLS-IN-TLS нету, из-за мультиплексации ( с паддингом). Мультиплексация в принципе дело православное
Для крупного да, не спорю. Но если так сделают то люди моментально просекут и не будут маскироваться под этих крупные домены. Не целесобразно банить
И я про vision, я возможно неправильно сформилировал свою мысль. Vision имеет проблемы с TLS-in-TLS, а Reality - нет. Если возвращаться к Вашему изначальному вопросу, что нету разницы, то получается это не так. Крайне извиняюсь, в xtls-rprx-vision решена данная проблема на 99%.
Reality может устранить характеристики отпечатков пальцев сервера tls.
xtls-rprx-vision может устранить характеристики tls-in-tls.
utls может устранить характеристики отпечатков клиентских tls.
Подробнее (много букв)
TLS in 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 можно считать абсолютно безопасным, но для проверяющего, помимо информации о взломе, также может быть использована некоторая дополнительная информация для идентификации этих 5 пакетов.
В этом суть так называемого TLS при обнаружении TLS.
Если интересно можете почитать на github полную статью (Английский язык): examples/xtls-vision/README.md at main · seakfind/examples · GitHub
а если в кратце, то размеры этих пакетов что-то около статичны и разработчики xtls-vision добавляют туда информации чтобы осложнить индификацию, но насчёт таймингов?
"Наиболее очевидной особенностью являются длины этих 5 пакетов.
Первый пакет очень короткий, и единственная переменная — это адрес назначения.
Второй пакет также очень короткий и практически фиксированный.
Третий пакет короткий, имеет очень мало изменений, почти единственная переменная — это целевой SNI.
Длина четвертого пакета сильно варьируется.
Пятый пакет очень короткий, с небольшими изменениями.
Можно интуитивно почувствовать, что характеристики длины этих пакетов на самом деле очень очевидны. В Vision наш подход к этому также весьма прост: мы заполняем длину каждого короткого пакета до интервала 900–1400 байт. Обратите внимание, что этот метод отличается от традиционного случайного добавления заполнения. Мы не слепо добавляем данные ко всем пакетам, а основываемся на нашем анализе внутреннего трафика, целенаправленно добавляя данные к характерным пакетам процесса TLS-рукопожатия."
Если пользователь отправляет пакет на сервер, это называется C, а противоположное направление называется S. Может ли рецензент определить, что это соединение TLS в TLS, основываясь на данных о временной последовательности, например, CSCSC, и их характеристиках временных интервалов?
Мы считаем, что этого недостаточно для вывода, и Vision не рассматривает этот аспект.
Многие разработчики упоминают MUX-мультиплексирование как способ противодействия обнаружению TLS в TLS. Это действительно оказывает маскирующий эффект в данном контексте. Если в туннеле мультиплексируются два разных TLS-соединения, существует вероятность формирования различных временных характеристик, таких как CCSSCC.
По факту Вы назвали основные причины почему steal oneself используют с Reality. В теории владелец сайта, под которого Вы маскируетесь может забанить Ваш ip за “большую назойливость” мягко говоря.
Но Вы можете быть легитимнее для РКН в случае если он захочет своими шаловливыми ручками в ручную заходить на Ваш домен. Чисто в теории можно на домен повесить, хммм, условно nextcloud или owncloud, а может что-то похожое для того что-бы думали что это Ваша “файловая помойка” и Вы туда сюда гоняете инфу, получается в несколько раз менее подозрительней чем качать террабайты инфы с новостного сайта или условной стоматологической клиники. Надеюсь Вы мою мысль поймали.
Шанс того что РКН будет ручками довольно мал. Возможно будет проверять те хостинги и домены где в месяц по 10+ ТБ бегают, таких мало будет, зато скорее всего это либо публичный бесплатный либо публичный платный VPN. Улов будет больше чем искать vps’ку где 200gb трафика в месяц и 2 человека сидят.
С MUX становиться всё более радужней, если так назвать можно
Многие разработчики упоминали мультиплексирование MUX против TLS при обнаружении TLS. В этом отношении это действительно сбивает с толку. Если в туннеле мультиплексируются два разных соединения TLS, существует вероятность формирования различных временных характеристик, таких как CCSSCC.
Вот оригинальные статьи если интересно: examples/xtls-vision/README.md at main · seakfind/examples · GitHub (перевод на английский)
XTLS Vision, fixes TLS in TLS, to the star and beyond · XTLS/Xray-core · Discussion #1295 · GitHub (Китайский)
HTTP2 это и так мультиплексное соединение, второй там не нужен
с insecure tls или самоподпис сертификатом все можно
Вы абсолютно правы, я xtls с rprx перепутал, крайне извиняюсь
И ниже более подробно описано. По факту проблемы нету, но в теории в техническом плане по временным интервалом могут.
Можно по конкретнее пожалуйста, я не понял что вы имели ввиду.
Гуглинг превёл меня к слудующему:
Использование небезопасных и устаревших протоколов может сделать соединения уязвимыми для таких эксплойтов, как DROWN (расшифровка RSA с использованием устаревшего и ослабленного шифрования eNcryption), нацеленная на конкретную уязвимость в реализации OpenSSL протокола SSLv2, и POODLE (заполнение Oracle при понижении устаревшего шифрования). Эта уязвимость позволяет злоумышленнику читать информацию, зашифрованную с помощью протокола SSLv3, в виде обычного текста, используя атаку «человек посередине» или подслушивание.
Это же по факту рай для цензоров или я не понял что-то
А с таким сертом будет ли вообще адекватно работать прокси? Мне теперь стало интересно, если такое можно реализовать + прикрутить список доменов и рандомить их до одного места)
Что-то вы все напутали. Vision как раз транспорт, который RPRX придумал, чтобы бороться с проблемой TLS-in-TLS. А Reality это система безапастности, ворующая TLS хендшейк, придумана, чтобы бороться с зондированием серверов. С безопасностью Reality могут использоваться и другие транспорты, например HTTP2 или gRPC, которые не лишены проблемы TLS-in-TLS.
А касательно вопроса топикстартера. На сегодня работает любая схема. Выбирайте, что нравится. Как раз китайцы все эти уловки придумывали, отвечая на реальные вызовы. Стал GFW мониторить ИИ дважды завернутый TLS - вот вам Vision как решения проблемы. Стали зондировать VPS - вот вам Реалити, чтобы маскировать сервер и uTLS, чтобы маскировать юзера. А пытаться угадать идеальную комбинацию решений безопасности “на будущее”, когда РКН ни с чем пока из этого не борется - бессмысленно. Вы не знаете, какой будет следующий ход цензора и что он изберет мишенью. И вы жонглируете протоколами “обезопасивая” себя от будущего, которое, возможно, никогда не настанет. А вместо этого, скажем, решат забанить скопом все IP вашего хостера, потому что решат, что какая-нибудь Aeza, например, слишком обнаглела, массово продавая решения для обхода блокировок. И что? Какая комбинация протоколов вам поможет?
Я же перечекнул своё же сообщение и ниже дополнил:
xtls-rprx-vision может устранить характеристики tls-in-tls.
Reality может устранить характеристики отпечатков пальцев сервера tls.
я перепутал xtls с rprx, а самое верхнее сообщение к сожалению уже изменить не могу, увы
Иностранная симка в роуминге 
Открой меня
Источник: Как перелезть через великую китайскую стену? — Talks — Форум
Я создал сервер в vultr в Нидерландах. Нашел в подсети какой-то непримечательный нидерландский сайт и настроил Xray Reality с маскировкой под этот домен. Думаю, что настроил правильно.
Прокси проработал несколько часов, я через него скачал андроид-студию и подобный хлам, потом начало всё тормозить и заглохло. Пару дней я был занят, сейчас проверяю - IP забанен. Причём я делал всё, чтобы не возбудить подозрения, на ssh заходил из другой сети, по сути через GFW мои запросы шли только на 443 порт с этим непримечательным доменом.
На текущий момент полу-легальный способ использования нормального интернета для меня это купленная в каком-то левом сервисе ESIM которая роутит трафик через Гонконг. С ней всё работает без лишних телодвижений, но стоит денег - за 50 GB я отдал примерно 55 евро. Для бытовых нужд, думаю, это оптимальный вариант, всё просто работает без лишних телодвижений.
не поняли, но и не важно, insecure tls это пропуск проверки валидности сертификата, это позволяет делать MITM так что в обсуждении не нуждается
мы не в северной корее, для установки tls соединения не обязательно иметь сертификат яндекса или гос услуг, но даже с ними можно иметь несколько на 1 порте (через iptables пробросить порт 443 на два локальных с рандом распределением и пользоваться vless+h2)
я не в этом корне мыслю, как сервера будет относится к самописным сертификатам, любые сервера. Неужели нету никаких защит от такого?
Если это так то я всё правильно понял.
Если так можно и сайты серт съедят то получается что можно
Скоро актуальным станет xhttp
Если использовать софт, по типу noisy, вместе с мультиплексацией, причем несколько разных процессов нойзи, которые проксируются ещё сверху вашего реалити другим vless или vmess, и выходит интересная схемка
Почему не нужен? ещё как нужен! Нам все нужно!
vmess уже не актуальный и не устойчивый к блокировкам
GFW.report (Английский): Summary on Recently Discovered V2Ray Weaknesses
подкрепляю словами rprx (Китайский): 关于 23 3 3 判断部分的 代码特征的利用漏洞 · Issue #17 · XTLS/Go · GitHub
А зачем проксировать поверх? Наоборот от этого избавляться хотят.
Можно ссылку? Я не нашёл просто
Но не повсеместно, как я почитал это выглядит как обновление vision, исправление его косяков и добавление плюшек по типу QUIC H3 через CDN, xmux, ниже задержки и т.д. Но до сих пор требует своего домена. Я не думаю что много кто будет запариваться со своим доменом + nginx + caddy, если будет работать Reality.
Вот нашёл пример: Xray-examples/VLESS-TLS-SplitHTTP-CaddyNginx at main · XTLS/Xray-examples · GitHub
Насколько я понимаю, иметь свой домен сейчас - это просто правило хорошего тона и дополнительная степень свободы, стоит копейки, настраивается элементарно. А маскироваться под гугл/яшу/вэкашку на какой-нибудь Аезе, ну да, ни разу не палевно.
Кстати, по поводу своего домена - не уверен, reality совместно с xhttp вполне себе работает. И имеет свои плюсы, как то меньше количество открытых сессий
Да и разделение потоков звучит очень даже заманчиво. Мы ведь не знаем, как в будущем будет работать “черный ящик”, поэтому предположу, что xhttp даст много преимуществ
- Актуален, с некоторыми конфигурациями, как и obfs4.
- Я имею в виду цепочку VLESS(VPS1) - N(SERVER 2) - NOISY
- GitHub - 1tayH/noisy: Simple random DNS, HTTP/S internet traffic noise generator
Иначе говоря, провайдер будет видеть один коннект, а на самом деле внутри него подключение к разным сайтам + подключение (уже не мультиплексированное) к другому серверу (хоть публичному, хоть нет. Это не важно, как и протокол.), там так же noisy.
Опознать tls in tls не возможно, как и любая тайминг-шейпинг атака.
При чем в идеале, протокол должен быть отличный от того, что используется то есть не быть 2 reality, можно obfs4, vmess, shadowsocks, amneziawg, cloak, тд и тп, главное не reality и желательно шифрованный протокол (а ещё лучше, с паддингом).
В настройках noisy можно указывать домены не русские, но из-за “имитации кликов”, есть риск того, что вы попадете на русский домен, но емто не страшно если вы проксируете noisy, однако добавляется проблема - лишается один из главные свойств, в ответ на это можно проксировать через тор, а у него есть свойство (в случае определенной конфигурации и мостов), использовать разные мосты под разные подключения - то есть, вот есть у вас 5 мостов, тор будет случайно выбирать каждый из ниж под 15 разных подключений. Таким образом будет достигнута наша цель, дополнительно можно проделать такое же с любым публичным прокси и пустить через него noisy (естественно первичный сервер - ваш REALITY). Тогда будет идеально!
да… крыша моя сьехала шифером с крыши
Обновляйте 3X-UI, на днях XHTTP прикрутили, все работает. Хотите быть гуглом, будете гуглом.
Но тут суровые персы пишут, что у них Reality с маскировкой под популярные сервисы банят на раз-два, свои сайтики с небольшим трафиком живут дольше. По-хорошему для маскировки под чужой сайт надо искать сайт в свой подсети, сканировать порты, чтобы ваш IP вел себя как донор, это все не менее хлопотно настроить, чем свой домен.
Да, нужно только выпустить свой сертификат. Можно даже корневой выпустить без указания доменного имени и его использовать, но пока не понял, насколько это безопасно.
Это верно, но как бы не проморгать момент, когда будут практиковать не только блокировки. Совсем другой уровень ответственности.
Так ли нужен свой домен? Что его наличие принципиально меняет? Свой сайт будет и без домена работать, самоподписанные сертификаты тоже можно без домена выпустить. В чём ценность своего домена?
Можно подробнее, как работает XHTTP, тыкнуть меня в документацию или еще как-то?
Оригинал и перевод лежат здесь.
у аезы есть специальные сайты SNI в той же подсети что и сервер
Лично не вижу смысл тогда запариваться. Может если только он даёт какие-нибудь приемущества от vision или reality
Я обновил, даже до 2.4.9 Видимо я пока не понял как его настроить.
А ты сам прочитал пост? Там идёт речь про Иран, где маскируються под сайты которые в белом списке. И речь в основном идёт об объёме трафика, я думаю возможно это не обнаружение Reality GFW’ом, а используется что-то иное судя по тому что впс’ка умирает от кол-во трафика, а не из-за наличия Reality на нём. В этом же посте написано что после бана ssh рабботает нормально, бан порта?
В иране белый список, напоминаю.
RealityTLSScanner? GitHub - XTLS/RealiTLScanner: A TLS server scanner for Reality
Там думать особо не надо, пару комманд и нашёл донора, а домен ещё купить надо, эта та причина почему большенство вряд ли будут на vision и ему подобные переходить, а пытаться через free домены, типо duckdns начинает достовлять неудобство, чем преимущества. (Дольше сайты грузит, а если отвалиться то будут проблемы, ну по факту тот же Reality и выйдет)
Я уже понял, мы в лс списались и оказалось что мы вообще о разном говорили, я о сервер → сайт, а он про клиент → сервер.
RPRX не рекомендует использовать панели без https по умолчанию. 3x-ui тот же
Веб-панель — ВНИМАНИЕ: НЕ ИСПОЛЬЗУЙТЕ простые HTTP-панели, такие как 3X-UI , так как считается, что они были подкуплены Ираном GFW за поддержку простого HTTP по умолчанию и отказались изменить ( #3884 (комментарий) ), что уже привело к тому, что многие безопасность данных пользователей в последние несколько лет оказалась под угрозой. Если вы уже используете 3X-UI, переключитесь на следующие панели, которые проверены на поддержку только переадресации портов HTTPS и SSH:
На ntc тоже тема висит, решать только Вам Вниманию пользователей 3X-UI
Я бы предпочёл иметь “запас прочности”
Если для Reality - то просто как хороший тон, особо что-то не получите.
А если будете ставить что-то помимо Reality, а именно то что работает исключительно на TLS (я имею ввиду кнопку в панели, так-то и Reality на TLS работает) и Reality не поддерживает, то свой домен обязательно. Как вы тот же vision настроите без своего домена? Откроете сайт гугла или мелкомягких в cf и будете записи менять?))
Это верно, если ходить на панель напрямую. Если заставить панель слушать только 127.0.0.1 и прокидывать порт через ssh, то разницы никакой нет. Однако я говорил не про сертификаты для панели, а про сертификаты для своего сайта. Вроде бы где-то видел рекомендацию не использовать самоподписанные сертификаты, если проксируешься своим же сайтом, но найти сейчас не могу.
- Поднимаешь веб-сервер (с сайтом или без).
- Выпускаешь самоподписанные сертификаты.
- Настраиваешь либо TLS+VISION+FALLBACK, либо TLS+VISION+REALITY.
- В SNI указываешь что угодно или ничего.
С REALITY такое точно работает, с FALLBACK пока не тестировал. Ещё я выпускал только корневые сертификаты (без указания доменного имени), поэтому не уверен, что фокус с SNI работает, если указать в сертификате доменное имя. Пока не понял, проверяет ли XRay соответствие сертификата и SNI. Надо попробовать в DEST указать один сайт, а в SNI указать другой сайт.
TLS нормально заводится и без доменного имени.
Очевидно и бесспорно, если у злоумышленника есть доступ по ssh то никакие серты не помогут. Ну опять же, это рекомендация для большинства, которые не разберутся как так делать или им будет лень каждый раз по ssh подключаться.
Это как минимум бесполезно, для чего свой домен подписываться самоподписом? Если можно к cf привязать домен и там получить серты в разделе SSL абсолютно бесплатно.
Это как? Может быть vision + Reality + uTLS?
Просто звучит как Wireguard+Reality+Vmess
Научите, я в примерах такого не нашёл, видимо Вы знаете больше чем rprx))
Вам нужен домен, который указывает на IP-адрес сервера, и сертификат, например, от Let’s Encrypt.
Также вам потребуется Nginx (или любой другой веб-сервер, такой как Caddy).
А можете показать как в браузере сертификат выглядит и как его другие видят
А зачем козе баян? Для reality нет необходимости в этих действиях
Да, конечно. Ерунду написал, но вы поняли.
Выглядит вот так (я не стал заполнять никакие дополнительные поля типа доменного имени, страны, почты и так далее). Если попробовать в браузере открыть сайт с таким сертификатом, то будет показано предупреждение об угрозе безопасности, но сайт всё равно можно открыть (в Firefox будет замок с восклицательным знаком). Если добавить этот сертификат в систему в качестве доверенного, то предупреждение не будет показано.
Пример корневого сертификата (RSA 4096).
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
25:5e:51:87:21:7a:84:e1:87:31:8a:d4:1f:45:83:87:9e:71:d1:7a
Signature Algorithm: sha256WithRSAEncryption
Issuer:
Validity
Not Before: Dec 19 16:59:07 2024 GMT
Not After : Dec 19 16:59:07 2027 GMT
Subject:
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:de:8b:ed:ff:40:f6:6b:ea:33:c2:fb:ad:84:66:
cd:62:a1:39:b6:c3:00:03:0f:d8:fc:4e:de:41:2c:
db:a6:b6:9f:4a:73:0f:fd:00:04:0a:8e:8c:97:6f:
c5:c3:a6:de:e2:d5:d6:db:10:e1:e1:aa:89:27:37:
5c:e8:c7:f7:ab:80:7a:c1:dc:c9:ba:1f:df:11:1e:
45:64:09:50:04:35:5b:8b:fc:57:28:50:3c:18:65:
7e:f0:b4:89:90:f8:24:73:aa:57:23:96:a1:d7:dd:
c6:52:27:88:77:ce:ac:9f:d9:f8:7b:05:e6:fa:10:
3b:38:c0:2d:b4:a3:c1:a8:75:26:8d:9d:3b:f8:95:
3b:0e:30:1e:01:79:83:4b:2a:8f:7a:10:dc:f7:7c:
b7:78:f0:5c:39:1a:fc:cd:7c:29:12:a5:ff:ab:26:
db:f7:24:c0:a7:0f:28:20:26:9f:57:a1:75:5d:6b:
42:7d:50:1a:ce:19:9f:58:95:33:8e:89:be:71:1e:
0f:55:fd:96:49:41:36:1c:0b:79:54:80:c6:a7:50:
86:1c:1a:af:5e:1a:28:57:36:c0:74:b1:4e:c9:60:
2c:cf:c0:08:5e:58:c9:24:08:e8:ce:05:ec:4c:d1:
8b:51:55:28:d1:93:df:85:fe:8d:4c:1f:b6:a1:d5:
4d:2a:dd:87:43:5d:fe:2a:83:f7:cc:d6:9c:b3:68:
14:ae:58:30:53:92:36:00:01:d3:95:a5:76:dc:45:
b9:73:87:d9:30:f1:fe:70:69:77:53:40:84:42:39:
74:1d:6e:aa:6c:f5:02:53:ab:91:e5:a4:58:47:20:
9a:30:25:56:92:ce:3d:a5:98:c4:e6:4c:4c:63:ab:
46:f3:dd:79:3d:a0:b6:59:fe:eb:ac:0a:d8:22:72:
64:6d:e8:7a:34:2a:7e:c3:5d:cd:6a:c4:a7:39:d5:
d7:cf:3d:23:f3:60:9d:35:37:41:3a:f6:b6:1c:29:
36:66:fc:1d:ce:c3:1a:fa:cf:84:cb:64:43:d8:1f:
0c:36:1a:40:d6:20:61:3a:77:5b:53:2a:83:cc:86:
43:e8:24:f4:f2:da:0f:b7:ab:c0:89:84:b2:2b:2d:
22:6b:7f:b8:a1:d1:ff:c3:bd:6d:68:9b:b9:a2:ed:
73:67:a7:ec:01:05:25:41:ab:9f:78:4c:4b:1b:c8:
87:7e:50:1b:0d:79:27:30:1c:2b:e4:1f:87:c8:6d:
f7:e9:d1:ee:be:94:f7:bc:9b:1b:4c:29:a4:55:3e:
c1:fa:c2:bd:77:5d:16:2f:47:4f:30:41:48:15:4c:
73:12:d7:d6:b1:8d:80:8e:ed:07:29:da:07:d7:f8:
aa:37:45
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
CF:D0:49:AF:94:DC:7E:48:4B:A6:40:A2:00:EA:43:0A:81:10:CA:6E
X509v3 Authority Key Identifier:
CF:D0:49:AF:94:DC:7E:48:4B:A6:40:A2:00:EA:43:0A:81:10:CA:6E
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
58:ea:77:cf:36:72:a4:db:55:25:98:c2:98:8e:a0:d9:82:b8:
38:57:c9:4a:f7:4f:0f:5a:f4:40:7d:c2:da:a0:12:50:7a:4a:
ed:37:17:93:ab:45:2f:03:e8:13:7f:65:ed:75:94:b4:a2:d5:
b9:e9:bf:e1:1e:96:42:78:c3:e7:e0:4e:a3:2d:6e:85:fa:b6:
34:f9:76:be:29:cb:1d:1a:16:72:cf:fb:16:97:48:01:85:ab:
f4:57:b2:5a:9d:79:cd:07:3e:d4:40:af:f9:fa:1d:25:a5:09:
44:00:ec:ab:c8:b3:27:20:77:10:d2:9f:f0:e0:8b:f9:43:fd:
ac:9e:f6:6b:61:f2:59:80:a3:ad:b4:07:82:52:65:fc:24:ba:
f3:75:ee:97:ee:0f:12:43:73:a6:bc:48:84:cd:8e:f4:ba:8d:
ab:dc:70:e7:38:6c:67:7f:d3:93:4e:0a:a9:82:eb:cb:b5:a5:
cc:10:e5:20:5e:8f:d0:45:8f:70:d7:eb:ab:71:6f:ad:2e:d8:
19:b1:2e:fa:16:d1:1b:4d:aa:19:60:6e:89:d7:e7:6b:06:d9:
3f:04:d5:2d:5a:6d:dd:3c:9f:21:65:02:b9:18:39:fc:58:36:
20:d1:4a:84:6f:3e:2b:27:0d:dd:f1:ca:57:f5:5d:b2:d6:1b:
60:a6:60:45:4f:12:f6:5e:fa:05:ae:33:53:ce:43:2b:86:73:
a5:58:55:97:40:bd:c8:c4:17:1c:ef:5f:b5:63:3f:b8:08:89:
2d:91:89:aa:61:1b:ba:50:cf:5b:ed:a8:04:89:eb:6a:ae:92:
1f:83:39:00:65:6c:fe:6b:42:41:f1:2a:f4:93:ce:0d:f1:84:
01:d5:8d:ed:62:51:83:a2:2d:6d:02:43:9d:65:11:33:13:6c:
52:97:6c:93:11:6d:7b:45:18:b8:cc:df:96:58:60:db:3f:77:
4e:df:29:2c:c3:be:4b:c4:24:34:cd:88:19:92:84:8a:41:27:
2b:c5:65:cc:1c:c5:cd:3c:5a:c1:8c:bb:1f:bf:03:d4:bf:08:
93:7d:c3:0b:76:7f:2c:ee:7e:96:12:37:fa:c5:53:d7:5a:3c:
c6:d9:da:de:94:95:cc:63:0b:b1:98:61:36:40:00:62:d0:54:
90:4f:70:3e:20:17:36:5e:2b:4e:a9:2f:b7:00:01:25:06:7a:
b1:cc:ac:04:17:a5:e7:f8:70:d0:4d:71:16:5e:92:bd:71:01:
6c:1b:2c:6a:e8:6a:61:da:50:ee:4e:89:14:15:7d:a7:5c:f9:
c8:5f:51:fe:d7:9f:17:16:03:ec:c9:bb:62:b7:0a:f2:37:99:
23:fe:40:f2:3d:3d:26:bf
-----BEGIN CERTIFICATE-----
MIIE4TCCAsmgAwIBAgIUJV5RhyF6hOGHMYrUH0WDh55x0XowDQYJKoZIhvcNAQEL
BQAwADAeFw0yNDEyMTkxNjU5MDdaFw0yNzEyMTkxNjU5MDdaMAAwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDei+3/QPZr6jPC+62EZs1ioTm2wwADD9j8
Tt5BLNumtp9Kcw/9AAQKjoyXb8XDpt7i1dbbEOHhqoknN1zox/ergHrB3Mm6H98R
HkVkCVAENVuL/FcoUDwYZX7wtImQ+CRzqlcjlqHX3cZSJ4h3zqyf2fh7Beb6EDs4
wC20o8GodSaNnTv4lTsOMB4BeYNLKo96ENz3fLd48Fw5GvzNfCkSpf+rJtv3JMCn
DyggJp9XoXVda0J9UBrOGZ9YlTOOib5xHg9V/ZZJQTYcC3lUgManUIYcGq9eGihX
NsB0sU7JYCzPwAheWMkkCOjOBexM0YtRVSjRk9+F/o1MH7ah1U0q3YdDXf4qg/fM
1pyzaBSuWDBTkjYAAdOVpXbcRblzh9kw8f5waXdTQIRCOXQdbqps9QJTq5HlpFhH
IJowJVaSzj2lmMTmTExjq0bz3Xk9oLZZ/uusCtgicmRt6Ho0Kn7DXc1qxKc51dfP
PSPzYJ01N0E69rYcKTZm/B3Owxr6z4TLZEPYHww2GkDWIGE6d1tTKoPMhkPoJPTy
2g+3q8CJhLIrLSJrf7ih0f/DvW1om7mi7XNnp+wBBSVBq594TEsbyId+UBsNeScw
HCvkH4fIbffp0e6+lPe8mxtMKaRVPsH6wr13XRYvR08wQUgVTHMS19axjYCO7Qcp
2gfX+Ko3RQIDAQABo1MwUTAdBgNVHQ4EFgQUz9BJr5TcfkhLpkCiAOpDCoEQym4w
HwYDVR0jBBgwFoAUz9BJr5TcfkhLpkCiAOpDCoEQym4wDwYDVR0TAQH/BAUwAwEB
/zANBgkqhkiG9w0BAQsFAAOCAgEAWOp3zzZypNtVJZjCmI6g2YK4OFfJSvdPD1r0
QH3C2qASUHpK7TcXk6tFLwPoE39l7XWUtKLVuem/4R6WQnjD5+BOoy1uhfq2NPl2
vinLHRoWcs/7FpdIAYWr9FeyWp15zQc+1ECv+fodJaUJRADsq8izJyB3ENKf8OCL
+UP9rJ72a2HyWYCjrbQHglJl/CS683Xul+4PEkNzprxIhM2O9LqNq9xw5zhsZ3/T
k04KqYLry7WlzBDlIF6P0EWPcNfrq3FvrS7YGbEu+hbRG02qGWBuidfnawbZPwTV
LVpt3TyfIWUCuRg5/Fg2INFKhG8+KycN3fHKV/VdstYbYKZgRU8S9l76Ba4zU85D
K4ZzpVhVl0C9yMQXHO9ftWM/uAiJLZGJqmEbulDPW+2oBInraq6SH4M5AGVs/mtC
QfEq9JPODfGEAdWN7WJRg6ItbQJDnWURMxNsUpdskxFte0UYuMzfllhg2z93Tt8p
LMO+S8QkNM2IGZKEikEnK8VlzBzFzTxawYy7H78D1L8Ik33DC3Z/LO5+lhI3+sVT
11o8xtna3pSVzGMLsZhhNkAAYtBUkE9wPiAXNl4rTqkvtwABJQZ6scysBBel5/hw
0E1xFl6SvXEBbBssauhqYdpQ7k6JFBV9p1z5yF9R/tefFxYD7Mm7YrcK8jeZI/5A
8j09Jr8=
-----END CERTIFICATE-----
Не хочется опираться на чужой сайт, но домен покупать тоже не хочется, поэтому решил поэкспериментировать. Жаль, Let’s Encrypt не разрешает выпускать сертификаты на IP, поэтому приходится самоподписанные сертификаты использовать.
Что делать если рядом с вашим отлично настроенным прекрасно скрытым проксей в той же подсети располагаются миллионы микрочелов которым было плевать на настройку, ведь они настраивали всё по васяно гайдам где бахнул 3x панель и готово ? В итоге цензор явно видит что к этой подсети идут триллионы мегабайт и там очевиднейший обход блокировки. Очень сомневаюсь, что когда у РКН дойдут руки до влесса, они будут выпиливать точечно плохо настроенные серваки, а не закроют всё общежитие. Что думаете по этому поводу ?
Что вас там так пугает, не понимаю? Денег $5 в месяц за VPS платить им не жалко, а $1 в год за домен отдать жаба что ли душит? Ну, личные данные, может, смущают? Ну я под левыми на namechуeap зарегистрировал и никто меня не съел. Сложность? Чо там сложного? Зарегистрировал, прописал DNS записи, через 10 минут заработало, ввел одну команду, получил Let’s Encrypt сертификат, который сам будет обновляться автоматически и все, сидишь как белый человек с нормальным доменом и сертификатом. Что там еще может отталкивать? Зачем искать трудные окольные пути, если есть прямой и простой?
Во-первых, я люблю упрощать решения и избавляться от зависимостей (да, моё понимание простоты не совпадает с вашим). Во-вторых, доллар есть доллар.
Если я правильно понял, вы проксируетесь своим сайтом. Скажите, пожалуйста, какой вариант вы выбрали: REALITY или FALLBACK? И почему?
Ок, принято. Мы все здесь параноики, но на разную тему.
Reality, конечно. Он безопасней. Потому что XTLS с Fallback это хакнутая библиотека TLS и она имеет отпечаток языка Go, на котором написана, что в теории является мишенью для обнаружения, хотя пока на практике по этому признаку не щемят. А Reality не несет собственного TLS отпечатка вашего сервера, он ворует настоящее TLS соединение или просто перекидывает вас на ваш же Nginx, который “пахнет” тем же Nginx, что и любой веб-сервер на нем.
- Мне казалось, что uTLS нужен, чтобы скрывать отпечаток клиента, а не сервера.
- FALLBACK тоже работает с uTLS.
Поправьте, если ошибаюсь, но мне пока непонятна разница этих двух подходов. Пока что у меня складывается ощущение, что REALITY не нужен, если проксирование идёт через свой сайт.
uTLS - это user TLS, прикрывает отпечаток клиента.
Еще раз. XLTS модифицированная библиотека TLS, которая изображает соединение с веб-сервером. Её недостаток в том, что в ней есть потенциально идентифицирующие её паттерны. Для решения этой проблемы и была придумана новая схема безопасности - Reality. Которая не генерирует фальшивый хендшейк хакнутой библиотекой, а ворует реальный. Либо у чужого сервера, либо перебрасывает на ваш по схеме steal oneself, т.е. как бы “ворует” хендшейк у вашего же веб-сервера на том же IP живущем. А перебрасывать на этот ваш веб-сервер, Apache, Nginx или Caddy может и старый XTLS, для этого там есть Fallback. Это схема TLS+Fallback. Но она, еще раз, “пахнет” собой для потенциальных продвинутых алгоритмов цензора. В этом её недостаток. Короче. Reality новее и круче.
Недостаток Reality в том, что она не умеет ходить через CDN. В этом случае вам остается только старый XTLS, без вариантов. Настрайивайте Reality. К голому XTLS сегодня имеет смысл прибегать только когда Reality не работает. А щас и эту проблему, заставить Reality работать через CDN, китайцы пытаются решить в XHTTP.
Какие-то дает, учитывая (возможные) блокировки? xtls-xprx-vison
Это да, но с таким сертификатом, не знаю насчёт других браузеров, но Firefox отключит некоторые фишки, по типу автозаполнения паролей на сайтах
Я не осуждаю и даже поддерживаю эксперименты, но домен стоит не так уж и дорого, мне лично удалось купить .space за 2$. Да и с доменом можно делать не долько vision + TLS, а ещё и websocket, gRPC и т.д
Ну много кто хоститься у разных хостеров, всегда найдуться те, кто плохо настроит. Если она так делать будут то побочный эффект будет слишком маштабным. Даже в Иране и Китае таким не занимаются. Только Туркменистан таким занимается, но это вообще другой вопрос (не более они недавно из чс вынесли все ип vps ибо они такими нетотечными банами буквально забанили абсолютно всё, но сеёчас, как я знаю, до сих пор банят, но не так жёстко). Так что думаю нет, подсети вырезать не будут
Много факторов, не в плане безопасности даже. Если Вы будете слишком докучать владельцам домена, они погут Ваш ип пробанить. Если сайт, под который вы маскируетесь ляжет - то Ваш впн-чик тоже, и т.д
TLS?
Я думаю ради интереса и экспериментов, никто не знает что будет дальше. Лучше иметь знания наперёд
Преимущества? Нет. Если вы про голый vision. Как минимум vision + TLS
а XTLS-xprx-vision бывает без tls? Впрочем не важно, я о другом. Можно без использования xtls-xprx-vision реализовать защиту от tls in tls, например.
Я думаю что можно настроить без TLS через голый xray.
Главное нововведение vision это отсутствие TLS-in-TLS. А те варианты, в котором появляется TLS-in-TLS (очень редкие, по типу Клиент → Vless Server → OpenVPN → Tor) на данный момент не правяться vision, может, в xhttp исправили, но я пока что не тестил
Я вообще о другом, я к тому, что мультиплексация вполне себе заменяет (при должной конфигурации) xtls-xprx-vision, а вместе с padding-ом и вовсе белиссимо
Заменяет vision на что, я просто Вас не понимаю.
Ну я и запутал вас… Имею в виду, что можно не использовать flow, а только реалити + мультиплексация и получить все баффы xtls-xprx-vision и не быть подверженым tls in tls.
Таким образом multiplex/mux заменяет xtls-xprx-vision
Хм, насчёт не указывания flow’а ничего сказать не могу как и про связку MUX + Reality. Если хотите MUX не теряя преимущества vision есть XHTTP
Как я понял, его лучше использовать за CDN… Интересная штукенция однако
Я тоже так понял.
Буквально недавно появилось (хоть и был splitHTTP которому 100 лет в обед, но rprx обновил до XHTTP) документация прямо на глаза обновляется, за неделю раза в 3 разрослась. Как замена Reality или ws
Огромное вам спасибо за такой развёрнутый ответ! Если бы здесь можно было бы закреплять сообщения, то ваше я бы закрепил. Теперь я понял разницу этих подходов и заодно нашёл такой же ответ от разработчиков XRay: Vision and Reality, Which?.
Тогда лучшим выбором даже для своего сайта будет REALITY, но для меня остаётся не закрытым другой вопрос.
Может быть, кто-нибудь знает: где можно почитать подробнее про активное зондирование (active probing)? Как это работает в деталях? Появилась мысль, что сайт без доменного имени или с самоподписанным сертификатом может не пройти такой проверки, но, чтобы понять, нужно узнать, как сейчас работают методы зондирования.
BleedingWall: A Hematologic Examination on the Great Firewall
Chasing Shadows: A security analysis of the ShadowTLS proxy
Conjure: Summoning Proxies from Unused Address Space
DeResistor: Toward Detection-Resistant Probing for Evasion of Internet Censorship
Detecting probe-resistant proxies
Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes
Fingerprinting VPNs with Custom Router Firmware: A New Censorship Threat Model
GFWeb: Measuring the Great Firewall’s Web Censorship at Scale
How china detects and blocks shadowsocks
How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic
Identifying VPN Servers through Graph-Represented Behaviors
Measuring and Evading Turkmenistan’s Internet Censorship
NetShuffle: Circumventing Censorship with Shuffle Proxies at the Edge
Network Measurement Methods for Locating and Examining Censorship Devices
On Precisely Detecting Censorship Circumvention in Real-World Networks
OpenVPN is Open to VPN Fingerprinting
ScrambleSuit: A Polymorphic Network Protocol to Circumvent Censorship
Towards a Censorship Analyser for Tor
Learning more about the GFW’s active probing system
Active Probing
Наконец-то дошло. Вы можете в мегаполисе жить без паспорта, но при военном положении и комендатском часе это будет мягко говоря проблематично. Вся безопасность в современном интернете строится вокруг гарантий 3-ей стороны. Вам выдет сертификат внешний орган и он является гарантом вашей адекватности для всех, кто пытается установиться с вами TLS соединение. Нравится вам или нет, но безопасность в толпе это быть как все. С паспортом. А не с руками самому себе выданной справкой (самоподписной сертификат). Потому что без официального сертификата вы для всех мутный IP через который идет мутный трафик. Вы себя демаскируете и всем этим кричите, что вы стремный деятель. Вы первый кандидат на бан. Поэтому официальный сертификат вам в момент проверок придется предъявить, как паспорт по требованию полиции. Либо поддельный (XTLS, не совсем аналогия, но как бы). Либо украденный (Reality + чужой SNI). Либо свой легальный (Reality + steal oneself). Других вариантов нет.
Благодарю. Мощная подборка.