Это надо в hosts ковыряться, а активному агенту-сканеру РКН вы в hosts не залезете. :) Лучше уж ip своей прокси в любом dynamic dns сервисе зарегистировать и поставить его в TLS_DOMAIN. Всё красиво, все довольны.
Тут одно «но»: отдать невалидному клиенту MASK_HOST:MASK_PORT с захардкоженным google.com не получится — браузер заругается, что хост, на который пришли, и домен в полученном сертификате не совпадают.
И DPI мгновенно определит это опросом, в том случае, когда его пробросит на «реальный https» (если это настроено). Просто разницей в длине пакетов. :(
Сходу правило — «блокировать сайт, где TLS-соединения с разных клиентов дают существенно разную длину ApplicationData первого TLS-фрейма». Оно будет даже не слишком тяжёлым для DPI и не потребует активного сканирования https/tls DPI-агентом.
SSLH не может различить «просто TLS» и «OpenVPN в „tls-crypt“ режиме». По крайней мере, у меня это не заработало ни на 1.18-1 из штатных реп, ни на самособранном 1.20.
mtproto proxy, который прямо таки кричит в любой DPI помощнее «вот он я, берите меня, unknown proto!»
Почему? DPI никакого URL внутри TLS не увидит, как и не увидит того, что они не используются. Максимум — SNI (так никто не мешает указывать реальный dyndns-хост). DPI видит, что «на хост ходят по TLS» и всё. Расшифровать содержимое оно не может, не зная секрета. Попробует зайти на хост само — получит страничку с котиками (если в проксе настроен проброс невалидных коннектов на реальный веб-сервер).
Где я ошибаюсь, полагая, что у DPI нет критериев для вынесения предположения о содержимом TLS1.3 сессии?
Я бы с удовольствием отдавал точно ту cert chain, которую отдаёт мой Апач, который показывает РКН не знающим секрета юзерам котиков. Там честный-благородный LE, отчего ж не отдать. И выглядеть будет при возможном скане абсолютно нормально.
Я обратил внимание, что сгенерированный секрет с доменом google.com не содержит в конце символа суффикса «=». И с ним моб.клиент работает. А вот с моим доменом секрет имеет в конце суффикс «=» — и клиент ломается. Криво декодируется base64 в клиенте?
Отвечу сам себе — проблемы нет с более-менее свежими устройствами. Распознавание QR-кодов есть прямо в приложении камеры, причём ссылку типа tg:// она правильно передаёт в Телеграм.
У чёрной таблетки, как и у всех подобных устройств, нет одной-единственной фичи, без которой использовать их совершенно неудобно. Это режим passthru с переключением на BT/WiFi «по требованию». Т.е. должна быть возможность включать этот убердевайс в разрыв line-out(источник)→line-in(колонки), и только в момент начала стриминга на устройство оно бы отключало источник и начинало воспроизводить поток. Как это делают, например, практически все lan-enabled ресиверы с незапамятных времён (Denon X3000, например, уже умел).
Без этого ценность данных устройств примерно околонулевая. Дать им выделенные колонки? А не жирно? Дать колонки с возможностью переключения источника? А таких было не слишком-то много, да и производить лишние и глупые телодвижения… ну, такое.
В качестве варианта для форсированной миграции можно использовать автоматический «спонсорский канал» — подключить его на старом прокси, чтобы при подключении выводился канал с новыми настройками.
Переведите, пожалуйста, 1000 существующих и работающих клиентов в этот режим.
Ну, т.е. вы хотите автонастройку. Увы, её нет, в Telegram вообще нет корпоративного функционала. :( Мы будем делать корпоративную рассылку с url нового прокси и инструкцией, а старый через неделю отключим.
Кстати, очень плохо то, что он сам не умеет сканировать QR-код с настройками прокси без лишних приложений. В тыщу раз бы было проще.
Это надо в hosts ковыряться, а активному агенту-сканеру РКН вы в hosts не залезете. :) Лучше уж ip своей прокси в любом dynamic dns сервисе зарегистировать и поставить его в TLS_DOMAIN. Всё красиво, все довольны.
Тут одно «но»: отдать невалидному клиенту MASK_HOST:MASK_PORT с захардкоженным google.com не получится — браузер заругается, что хост, на который пришли, и домен в полученном сертификате не совпадают.
Сходу правило — «блокировать сайт, где TLS-соединения с разных клиентов дают существенно разную длину ApplicationData первого TLS-фрейма». Оно будет даже не слишком тяжёлым для DPI и не потребует активного сканирования https/tls DPI-агентом.
Я и прошу объяснить — КАК? По каким признакам?
Почему? DPI никакого URL внутри TLS не увидит, как и не увидит того, что они не используются. Максимум — SNI (так никто не мешает указывать реальный dyndns-хост). DPI видит, что «на хост ходят по TLS» и всё. Расшифровать содержимое оно не может, не зная секрета. Попробует зайти на хост само — получит страничку с котиками (если в проксе настроен проброс невалидных коннектов на реальный веб-сервер).
Где я ошибаюсь, полагая, что у DPI нет критериев для вынесения предположения о содержимом TLS1.3 сессии?
РКНне знающим секрета юзерам котиков. Там честный-благородный LE, отчего ж не отдать. И выглядеть будет при возможном скане абсолютно нормально.Я обратил внимание, что сгенерированный секрет с доменом google.com не содержит в конце символа суффикса «=». И с ним моб.клиент работает. А вот с моим доменом секрет имеет в конце суффикс «=» — и клиент ломается. Криво декодируется base64 в клиенте?
и порно. Всё на стандартном 443. «Вы знаете? Я счастлив.» © Друпи.PS: мобильный Telegram (андроид) сходит с ума от сгенерированной и втянутой ссылки на прокси с более-менее длинным TLS_DOMAIN. И просто зависает.
Без этого ценность данных устройств примерно околонулевая. Дать им выделенные колонки? А не жирно? Дать колонки с возможностью переключения источника? А таких было не слишком-то много, да и производить лишние и глупые телодвижения… ну, такое.
Ну, т.е. вы хотите автонастройку. Увы, её нет, в Telegram вообще нет корпоративного функционала. :( Мы будем делать корпоративную рассылку с url нового прокси и инструкцией, а старый через неделю отключим.
Кстати, очень плохо то, что он сам не умеет сканировать QR-код с настройками прокси без лишних приложений. В тыщу раз бы было проще.