[Из песочницы] Что делать, если у кабелей есть уши, или стеганографическое прокси
Мир цензуры
Дело в том, что в последнее время началось активное распространение роскомнадзоров, СОРМов, золотых щитов, корневых сертификатов, черных фургонов ФБР и прочих методов прослушки/ограничения/подмены трафика во всеми любимой сети Интернет.
На фоне этого, у многих началась болезнь, прекрасно описываемая фразой «у стен есть уши». И было бы это без повода —, но все ваши данные идут через маршруты, вам неизвестные, через черные коробки, вам не принадлежащие, сервера, вами не контролируемые, а скоро это все будет еще и сохраняться. Ну как тут не занервничать?
Говорят, шифрование всех спасет. Но так ли это? Опуская проблемы классической и современной криптографии, так или иначе, шифрованный трафик всегда можно относительно просто обнаружить и банально прикрыть канал передачи. И тут на помощь приходит стеганография.
Чтобы проникнуться и понять, зачем оно нам, посмотрим на классическую схему передачи трафика от Алисы к Бобу в интернете:
Учтем, что интернет и каналы связи в нем нам неподконтрольны и уязвимы by design. Более того, между Алисой и Бобом есть некто, контролирующие среду передачи и ограничивающие (прослушивающие/вставьте свое слово) их обмен сообщениями.
На самом деле, передача через данных через интернет все больше напоминает проблему заключенных.
А схема выглядит так:
Где Вилли — не садовник, как кажется на первый взгляд, а охранник, ограничивающий передачу любых сообщений к Бобу. Алиса же — свободный человек (или заключенный в другой камере), с которым Боб хочет общаться в обход охранника.
Соответственно, задача стеганографии в том, чтобы охранник просто не замечал обмена сообщениями. А кто именно является охранником — ркн или фургончик фбр — частные случаи.
А при чем здесь прокси?
- Боб — это ПО на контролируемом устройстве, через которое очень хочется свободного обмена информацией, вне зависимости от его положения в мире.
- Вилли — это злые провайдеры, регулирующие органы, корпоративные прокси-сервера и прочие, желающие этому обмену помешать.
- Алиса — это шлюз, через который мы получаем информацию из внешнего (или другого внутреннего) мира.
В зависимости от ситуации, между Алисой и Бобом может быть как контролируемый Вилли канал связи, так его (канала) может и не быть в принципе. Правды ради, стоит отметить, что мало кто полностью обрезает каналы связи, и даже за великим файероволом можно при желании посидеть в фейсбуке. Так что этот случай будет первый и простой вариант.
Стеганографический канал тогда будет создаваться просто поверх заранее известного канала, подконтрольного Вилли. Рассмотрим в качестве примера реализацию с использованием обычных сокетов.
Стегоканал создается подключением Боба к Алисе через сокет на установленном заранее порту.
Получившаяся схема отличается простотой и надежностью. Но, это не совсем стеганография. Для Вилли вполне очевидно, что обмен картинками на нестандартных портах — неспроста. Частично можно снизить уровень подозрительности, используя стандартные порты и протоколы. Например, обмен файлами через FTP. В целом, один из самых быстрых и удобных вариантов. Можно пользоваться, пока градус неадеквата и подозрительности со стороны Вилли не очень высок.
А теперь представим, что Вилли запретил обмениваться Бобу сообщениями с Алисой. Вообще.
Тогда для создания стеганографического туннеля (канала без прямой связи) необходим ресурс с общим доступом. Классическим примером являются социальные сети — доступные из большинства точек мира, публичные. Идеальный вариант для обмена стеганограммами, не совсем подходит для прокси ввиду необходимости большого потока информации. Однако, секъюрность требует жертв. В данном случае, жертвой падет скорость, но об этом чуть позже. Рассмотрим реализацию с использованием ВК в качестве общедоступной среды обмена:
Эта схема полагается на сторонний сервис, а значит, полностью зависит от него. С другой стороны, обмен картинками между пользователями не вызывает никаких подозрений, даже с высокой частотой (боты, по большей части, легальны). Из минусов получаем пониженную пропускную способность и возможность оказаться без линии связи в нужный момент — если обычно запасной канал является опциональным, то тут это обязательное условие работы.
А теперь о самой реализации и том, что вышло
Боб реализован в виде обычного прокси-ретранслятора типа [Socket-Stegochanel], слушающего определенный порт. Все данные, поступающие на него, он прячет в стегоконтейнеры с использованием заранее обговоренного алгоритма и посылает по стегоканалу Алисе. Все операции записи и извлечения проводятся с установленным заранее секретом (в стеганографии, в принципе, можно и без него, ограничений на реализацию нет).
Алиса типа [Stegochanel-Socket] принимает весь трафик от Боба по стегоканалу, извлекает его из стегоконтейнеров и перенаправляет на настоящий прокси сервер, который вы хотите использовать, выделяя для каждого экземпляра стегоканала отдельное подключение к прокси (чтобы не было путаницы). Ведь кто знает заранее, что за трафик и зачем понадобится пересылать, верно?
И как оно работает?
Для тестирования, в качестве прокси-сервера я арендовал дешевый ARM-сервер во франции, развернул на нем Ubuntu 16.10 и на ней Squid вместе с ретранслятором. Все замеры проводились из дома с интернетом на 5 Мбит/с через ADSL национальнейшего русского провайдера. Если кто-то хочет проверить на нормальной скорости — в конце оставлю ссылки на GitHub.
В качестве proof of concept я реализовал стегоканал поверх сокетов. Если будет интерес — аналогичное тестирование проведу и для реализации с VK в качестве среды обмена. В качестве алгоритма — свой собственный вариант метода LSB с максимальной емкостью примерно в четверть байт от общего числа пикселей, работающий с изображениями без сжатия, о котором, возможно, напишу позже. В качестве контейнера сначала использовалось одно единственное изображение Че Гевары в png разрешением 518×587.
Результаты тестирования в качестве прокси в firefox без каких-либо плагинов и доп. настроек:
- wikipedia.org — 1:13;
- en.wikipedia.org — 2:01, после этого общение с сервером продолжается, но контент весь уже загружен;
- google.com (.fr) — ~2 м, подсказки не работают, поисковая выдача грузится по минуте;
- duckduckgo.com — так и не загрузился в течение 10 минут;
- txti.es — ~3с на страницу. И правда, fast web pages;
- garfield.vexer.ru — 1:35. Реклама при этом не загрузилась (и адблок не нужен);
- reddit.com — грузится очень долго (больше 10 минут), что-то загружает, но терпения у вас вряд ли хватит;
- bing.com — 1:45 на полную загрузку. ~50 секунд на страницу поисковой выдачи;
- jcgonzalez.com — не загрузился;
- minergate.com — 4 м;
- vk.com — ~1 м, изображения догружаются дольше, диалоги работают шустро;
- linkedin.com — ~50c, но громадное изображение-фон будет грузиться еще долго;
- weather.com — не загрузился;
Стоит заметить, что подобные скорости (очень скромные, особенно, если посмотреть на календарь) объясняются не только тем, что стеганография передает избыточное количество информации, но и накладными расходами на сам стеганографический алгоритм. А ожидать от ARM-сервера за 3 зеленых президента чего-то необычного в плане производительности было бы странно. Аренда болеее быстрого сервера дает сильное ускорение (раза в 2 на старом слабом х86 сервере).
Отключив изображения и медиа-элементы, включив адблок, скорость можно повысить. Переместившись таки методом на лет 10 (15?) назад, получаем соответствующую тому же времени скорость загрузки страниц. Но в целом, вывод остается тем же — такое стеганографическое прокси годится только для экстренных случаев.
Впечатления от такого интернета далеко не положительные. Возможно, с другими методами стеганографии, или просто оптимизируя мой, можно добиться больших результатов. Однако, пока что, получившийся Proof of Concept говорит лишь о том, что такое прокси годится только для экстренных случаев. Что, на самом деле, не особо удивительно. Или неожиданно. Большая часть проблем с задержками — тайминги при рукопожатии в ssl. Вот вам и повсеместное насаждение https.
Подумав, было решено заменить бедного статичного Че Гевару на случайные изображения с минимальной избыточностью. Ведь если передавать не в 16 раз больше информации, а в 4, то теоретически, получим приятный бонус к скорости. Благо, генераторов случайных изображений заданного размера в интернете полно.
Результаты при повторном тестировании:
- wikipedia.org — 21с;
- en.wikipedia.org — 21с;
- google.com (.fr) — 23с до работоспособности, 45с до полной загрузки, 3с на выдачу;
- duckduckgo.com — 45с до работоспособности, 55с до полной загрузки;
- txti.es — мгновенно;
- garfield.vexer.ru — 1:10 вместе с рекламой, последующие стрипы грузятся секунд по 10, так как все самое тяжелое уже в кеше;
- reddit.com — 44с без контента, 1:20 с его превью;
- bing.com — 13с полная загрузка, 5с на выдачу с картинками;
- jcgonzalez.com — упал, но 404 выдает быстро;
- minergate.com — 1 м;
- vk.com — 23c, страницы с сообщениями по секунд 10 и больше, в зависимости от содержимого;
- linkedin.com — 40c;
- weather.com — не загрузился;
С таким интернетом жить уже можно, особенно, если мало альтернатив. Стеганографическая стойкость падает с повышением отношения шум/полезная информация, жертвовать или нет — решать не мне.
На этом считаю эксперимент завершенным. Исходники, бинарники, инструкции по применению и помощи находятся на гитхабе ниже. Если будут дополнительные вопросы — буду ждать в комментариях.
→ GitHub
