Это возможно, но очень недружелюбно к конечному пользователю туннеля и администратору сервера:
Нужно хостить конкретный новый сайт типа funny-cats-not-suspicious.ru, чтобы его бэк мог после TLS-терминирования прочитать расшифрованное тело GET/POST и отправить ответ обратно. Соответственно, весь сайт можно полностью заблокировать по SNI после первого подозрения.
Теоретически, можно использовать любой чужой двунаправленный разрешённый канал передачи (типа чата Avito или Яндекс.Телемост, но это другое семейство подходов).
На клиентской стороне снова придётся использовать что-то похожее на браузер, смешивающее и расщепляющее обратно настоящие смешные картинки с полезным proxy-трафиком.
Иначе, если используем настоящий браузер, фронтенд сайта должен общаться с условным 127.0.0.1:12345 в LAN (или на самой машине/смартфоне), на котором слушает TUN- или проще socks-proxy, который как раз перекидывает трафик app <-> socks <-> browser[cats.ru].
Пока писал, понял, что подход интересный, и неплохо формализуется: достаточно иметь несложную JS-либу для фронтенда/бэкенда, и клиентское/серверное приложения, с которыми общается эта либа (большую часть можно собрать из готовых кирпичей).
Минусы:
в п.1, бэк сайта должен быть полностью подконтролен администратору входной ноды;
как сказано, сайт очень просто заблокировать по SNI, если соединение без Encrypted Client Hello;
плохая защита от реверс-инжинирига: в JS на клиентской стороне даже с обфускацией можно будет явно найти попытку соединения с условным 127.0.0.1:12345 — значит, сайт-то непростой, в бан его.
сайт-носитель должен быть постоянно открыт (решаемо, но может быть противно, держать на том же устройстве или в LAN работающий набор вкладок).
Плюсы:
можно прятаться за CDN;
носитель соединения — настоящий браузер, отличить его от настоящих соединений при хорошем shaping нереально;
ну и собственно shaping — можно сколько угодно аккуратно троттлить и фрагментировать трафик, делая его неотличимым от обычного сёрфинга.
(Микрореклама: работаю над проектом FPS, который, теоретически, способен использовать любые TLS-носители для передачи полезного трафика.)
Боже, какой жидкий нейросетевой выпердыш: во-первых, текст вступления слово в слово содран с оригинальной статьи, а во-вторых, статья пропущена через какую-то самую дешевую LLM, сготовившую несуразную кашу из терминов без понимания сути и идей (и, вероятно, в основном на основе сбивающего с толку вступления).
Остальные посты, смотрю, такие же. Держите-ка минус в карму, негоже захламлять хороший сайт. И спасибо, подписался, буду с умом тратить голоса.
Это возможно, но очень недружелюбно к конечному пользователю туннеля и администратору сервера:
Нужно хостить конкретный новый сайт типа
funny-cats-not-suspicious.ru, чтобы его бэк мог после TLS-терминирования прочитать расшифрованное тело GET/POST и отправить ответ обратно. Соответственно, весь сайт можно полностью заблокировать по SNI после первого подозрения.Теоретически, можно использовать любой чужой двунаправленный разрешённый канал передачи (типа чата Avito или Яндекс.Телемост, но это другое семейство подходов).
На клиентской стороне снова придётся использовать что-то похожее на браузер, смешивающее и расщепляющее обратно настоящие смешные картинки с полезным proxy-трафиком.
Иначе, если используем настоящий браузер, фронтенд сайта должен общаться с условным
127.0.0.1:12345в LAN (или на самой машине/смартфоне), на котором слушает TUN- или проще socks-proxy, который как раз перекидывает трафикapp <-> socks <-> browser[cats.ru].Пока писал, понял, что подход интересный, и неплохо формализуется: достаточно иметь несложную JS-либу для фронтенда/бэкенда, и клиентское/серверное приложения, с которыми общается эта либа (большую часть можно собрать из готовых кирпичей).
Минусы:
в п.1, бэк сайта должен быть полностью подконтролен администратору входной ноды;
как сказано, сайт очень просто заблокировать по SNI, если соединение без Encrypted Client Hello;
плохая защита от реверс-инжинирига: в JS на клиентской стороне даже с обфускацией можно будет явно найти попытку соединения с условным
127.0.0.1:12345— значит, сайт-то непростой, в бан его.сайт-носитель должен быть постоянно открыт (решаемо, но может быть противно, держать на том же устройстве или в LAN работающий набор вкладок).
Плюсы:
можно прятаться за CDN;
носитель соединения — настоящий браузер, отличить его от настоящих соединений при хорошем shaping нереально;
ну и собственно shaping — можно сколько угодно аккуратно троттлить и фрагментировать трафик, делая его неотличимым от обычного сёрфинга.
(Микрореклама: работаю над проектом FPS, который, теоретически, способен использовать любые TLS-носители для передачи полезного трафика.)
Боже, какой жидкий нейросетевой выпердыш: во-первых, текст вступления слово в слово содран с оригинальной статьи, а во-вторых, статья пропущена через какую-то самую дешевую LLM, сготовившую несуразную кашу из терминов без понимания сути и идей (и, вероятно, в основном на основе сбивающего с толку вступления).
Остальные посты, смотрю, такие же. Держите-ка минус в карму, негоже захламлять хороший сайт. И спасибо, подписался, буду с умом тратить голоса.