[Из песочницы] Что делать, если у кабелей есть уши, или стеганографическое прокси

День добрый. Сегодня я расскажу вам об одном виде паранойи, связанном с последними тенденциями в сфере защиты государством населения от информации, и методе его лечения.
image

Мир цензуры


Дело в том, что в последнее время началось активное распространение роскомнадзоров, СОРМов, золотых щитов, корневых сертификатов, черных фургонов ФБР и прочих методов прослушки/ограничения/подмены трафика во всеми любимой сети Интернет.

На фоне этого, у многих началась болезнь, прекрасно описываемая фразой «у стен есть уши». И было бы это без повода —, но все ваши данные идут через маршруты, вам неизвестные, через черные коробки, вам не принадлежащие, сервера, вами не контролируемые, а скоро это все будет еще и сохраняться. Ну как тут не занервничать?

Говорят, шифрование всех спасет. Но так ли это? Опуская проблемы классической и современной криптографии, так или иначе, шифрованный трафик всегда можно относительно просто обнаружить и банально прикрыть канал передачи. И тут на помощь приходит стеганография.

Чтобы проникнуться и понять, зачем оно нам, посмотрим на классическую схему передачи трафика от Алисы к Бобу в интернете:

c03f3d970a7c4df98f5dc561264654ba.jpg

Учтем, что интернет и каналы связи в нем нам неподконтрольны и уязвимы by design. Более того, между Алисой и Бобом есть некто, контролирующие среду передачи и ограничивающие (прослушивающие/вставьте свое слово) их обмен сообщениями.

На самом деле, передача через данных через интернет все больше напоминает проблему заключенных.

А схема выглядит так:

7fbb791ceb6f4e1886b052b76e3bf8f4.jpg

Где Вилли — не садовник, как кажется на первый взгляд, а охранник, ограничивающий передачу любых сообщений к Бобу. Алиса же — свободный человек (или заключенный в другой камере), с которым Боб хочет общаться в обход охранника.

Соответственно, задача стеганографии в том, чтобы охранник просто не замечал обмена сообщениями. А кто именно является охранником — ркн или фургончик фбр — частные случаи.

А при чем здесь прокси?


  • Боб — это ПО на контролируемом устройстве, через которое очень хочется свободного обмена информацией, вне зависимости от его положения в мире.
  • Вилли — это злые провайдеры, регулирующие органы, корпоративные прокси-сервера и прочие, желающие этому обмену помешать.
  • Алиса — это шлюз, через который мы получаем информацию из внешнего (или другого внутреннего) мира.

В зависимости от ситуации, между Алисой и Бобом может быть как контролируемый Вилли канал связи, так его (канала) может и не быть в принципе. Правды ради, стоит отметить, что мало кто полностью обрезает каналы связи, и даже за великим файероволом можно при желании посидеть в фейсбуке. Так что этот случай будет первый и простой вариант.

Стеганографический канал тогда будет создаваться просто поверх заранее известного канала, подконтрольного Вилли. Рассмотрим в качестве примера реализацию с использованием обычных сокетов.

Стегоканал создается подключением Боба к Алисе через сокет на установленном заранее порту.

7027e91666d34eda97410362ac232fad.jpg

Получившаяся схема отличается простотой и надежностью. Но, это не совсем стеганография. Для Вилли вполне очевидно, что обмен картинками на нестандартных портах — неспроста. Частично можно снизить уровень подозрительности, используя стандартные порты и протоколы. Например, обмен файлами через FTP. В целом, один из самых быстрых и удобных вариантов. Можно пользоваться, пока градус неадеквата и подозрительности со стороны Вилли не очень высок.

А теперь представим, что Вилли запретил обмениваться Бобу сообщениями с Алисой. Вообще.


Тогда для создания стеганографического туннеля (канала без прямой связи) необходим ресурс с общим доступом. Классическим примером являются социальные сети — доступные из большинства точек мира, публичные. Идеальный вариант для обмена стеганограммами, не совсем подходит для прокси ввиду необходимости большого потока информации. Однако, секъюрность требует жертв. В данном случае, жертвой падет скорость, но об этом чуть позже. Рассмотрим реализацию с использованием ВК в качестве общедоступной среды обмена:
a182bbb8ae9f45d29ed749e8b644246e.jpg

Эта схема полагается на сторонний сервис, а значит, полностью зависит от него. С другой стороны, обмен картинками между пользователями не вызывает никаких подозрений, даже с высокой частотой (боты, по большей части, легальны). Из минусов получаем пониженную пропускную способность и возможность оказаться без линии связи в нужный момент — если обычно запасной канал является опциональным, то тут это обязательное условие работы.

А теперь о самой реализации и том, что вышло


Боб реализован в виде обычного прокси-ретранслятора типа [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

Комментарии (0)

© Habrahabr.ru