Программа SoftEnter VPN Client.

В связи с реальной угрозой расширения карательных функций «Антипиратского закона» и возможным началом переноса его действия на простых пользователей, а именно, возможным введением штрафов за скачивание пиратского контента (фильмов музыки программ и так далее), продолжаю знакомить посетителей моих сайтов с информацией, как этих штрафов избежать, то есть, как скачивать с интернета АНОНИМНО. Ранее, я показал, как скачивать анонимно по прямым ссылкам и с торрентов. В данной статье рассмотрим один из способов, как зашифровать весь интернет-трафик. Шифрование всего интернет-трафика позволит вам стать полностью анонимным в интернете, сменив свой IP-адрес, на сторонний. После смены IP-адреса при помощи предлагаемого в данной статье приложения никто из посторонних уже не сможет узнать какие сайты вы посещали, что скачивали, в том числе будет зашифрован и ваш интернет-трафик в торрент-клиенте.
Речь пойдет о приложении под названием SoftEnter VPN Client. Это клиентская программа для связи с сервисом под названием VPN Gate.
Сервис VPN Gate - это экспериментальный проект Высшей школы университета г. Цукуба (Япония). Идея проекта заключается в организации добровольцами публичной общественной сети туннелей VPN, которые создаются, с помощью специального программного обеспечения, и бесплатно предоставляются в публичное общее пользование. Подключиться к ним может каждый желающий.
Частные публичные сети VPN Gate предоставляются обычными людьми, а не компаниями и, даже гипотетическая возможность получения логов (истории посещённых Вами сайтов и истории скачивания) по запросу компетентных органов исключена. Сервис VPN Gate и создавался для того, чтобы дать возможность гражданам стран, где блокируются определённые сайты свободно и анонимно посещать их, но сервис можно использовать и для скачивания нужного вам контента, не опасаясь неприятных последствий.
Настроить работу программы SoftEnter VPN Client вовсе несложно. Сейчас покажу, как это сделать.

Для начала скачиваем на сайте разработчика по ссылке архив с установочным файлом программного обеспечения SoftEnter VPN Client.

Кстати, информация для тех, кто уже пользовался универсальным моментальным немецким клеем Nano Kleber и для тех, кто еще не знаком с нашим продуктом - наш клей кардинально изменился.
Естественно в лучшую сторону. Во-первых, изменился внешний вид упаковки и флаконов клея. Во-вторых, объем флаконов увеличился на треть! Теперь вес флакона 31,5 граммов, флакона со сварочным гранулятом, 25 граммов.
И главное, улучшено качество самого клея. По многочисленным просьбам покупателей, клей стал гуще. Это позволяет работать с ним, перед сжатием (склеиванием) не торопясь. Срок подготовки увеличен в 2 раза! При этом его цена осталась прежней.
Подробнее узнать о клее Nano Kleber можно на нашем официальном сайте по ссылке . Там же можно его и заказать. Доставка - по всей России.

После скачивания архива распаковываем папку с установочным файлом на рабочий стол.

Открываем ее и запускаем установку программного обеспечения SoftEnter VPN Client.

После установки программного обеспечения SoftEnter VPN Client запускаем его в работу.

Выбираем один из серверов VPN и подключаемся к нему.

После подключения к выбранному серверу VPN весь ваш интернет-трафик будет перебрасываться через сторонний сервер, надежно скрывая ваши действия в интернете.

То что вы подключены к выбранному вами серверу VPN легко можно узнать, посетив один из сервисов проверки IP-адресов. Найти их несложно. В поисковой строке любого поисковика, например, в Яндексе, пишем поисковую фразу «проверка ip».

Отключить VPN-соединение просто. В трее после установки программного обеспечения SoftEnter VPN Client появиться специальный значок. Кликните по нему правой кнопкой мыши и в выпавшем контекстном меню выберете нижнюю строчку отключения программы.

Как видите, зашифровать весь свой интернет-трафик при помощи программы SoftEnter VPN Client и сервиса VPN Gate совсем несложно.
В ближайшее время продолжим изучение темы шифрования интернет-трафика и рассмотрим еще один способ шифрования трафика при помощи сервисов VPN, напрямую, без использования сторонних приложений, а лишь меняя настройки интернет-соединения.

Вы думаете что ваша анонимность надежно защищена. Но к сожалению это не так. Существует один очень важный канал утечки вашей приватной информации — служба DNS. Но к счастью на это тоже придумано решения. Сегодня я раскажу как зашифровать свой DNS трафик с помощью утилиты DNSCrypt.

При использовании HTTPS или SSL твой HTTP трафик зашифрован, то есть защищен. Когда ты используешь VPN, шифруется уже весь твой трафик (конечно, все зависит от настроек VPN, но, как правило, так оно и есть). Но иногда, даже когда используется VPN, твои DNS-запросы не зашифрованы, они передаются как есть, что открывает огромное пространство для «творчества», включая MITM-атаки, перенаправление трафика и многое другое.

Тут на помощь приходит опенсорсная утилита DNSCrypt, разработанная хорошо известными тебе создателями OpenDNS, - программа, позволяющая шифровать DNS-запросы. После ее установки на компьютер твои соединения также будут защищены и ты сможешь более безопасно бороздить просторы интернета. Конечно, DNSCrypt - это не панацея от всех проблем, а только одно из средств обеспечения безопасности. Для шифрования всего трафика все еще нужно использовать VPN-соединение, но в паре с DNSCrypt будет безопаснее. Если тебя такое краткое объяснение устроило, можешь сразу переходить к разделу, где я буду описывать установку и использование программы.

Попробуем разобраться глубже. Этот раздел предназначен для настоящих параноиков. Если ты ценишь свое время, тогда можешь сразу перей ти к установке программы.
Итак, как говорится, лучше один раз увидеть, чем сто раз услышать. Посмотри на рисунок.

Допустим, клиент (ноутбук на рисунке) пытается обратиться к google.com Первым делом он должен
разрешить символьное имя узла в IP-адрес. Если же конфигурация сети такова, что используется DNS-сервер провайдера (незашифрованное соединение, красная линия на рисунке), то разрешение символьного имени в IP-адрес происходит по незашифрованному соединению.

Да, какие данные ты будешь передавать на dkws.org.ua, никто не узнает. Но есть несколько очень неприятных моментов. Во-первых, провайдер, просмотрев логи DNS, сможет узнать, какие сайты ты посещал. Тебе это нужно? Вовторых, вероятна возможность атак DNS спуфинг и DNS снупинг. Подробно описывать их не буду, об этом уже написано множество статей. В двух словах ситуация может быть следующей: некто между тобой и провайдером может перехватить DNS-запрос (а так как запросы не шифруются, то перехватить запрос и прочитать его содержимое не составит никакого труда) и отправить тебе «поддельный» ответ. В результате вместо того, чтобы посетить google.com, ты перейдешь на сайт злоумышленника, как две капли воды похожий на тот, который тебе нужен, введешь свой пароль от форума, ну а дальше развитие событий, думаю, ясно.

Описанная ситуация называется DNS leaking («утечка DNS»). DNS leaking происходит, когда твоя система даже после соединения с VPN сервером или Tor продолжает запрашивать DNS серверы провайдера для разрешения доменных имен. Каждый раз, когда ты посещаешь новый сайт, соединяешься с новым сервером или запускаешь какое-то сетевое приложение, твоя система обращается к DNS провайдера, чтобы разрешить имя в IP. В итоге твой провайдер или любой желающий, находящийся на «последней миле», то есть между тобой и провайдером, может получить все имена узлов, к которым ты обращаешься. Приведенный выше вариант с подменой IP-адреса совсем жестокий, но в любом случае есть возможность отслеживать посещенные тобой узлы и использовать эту информацию в собственных целях.

Если ты «боишься» своего провайдера или просто не хочешь, чтобы он видел, какие сайты ты посещаешь, можешь (разумеется, кроме использования VPN и других средств защиты) дополнительно настроить свой компьютер на использование DNS серверов проекта OpenDNS (www.opendns.com). На данный момент это следующие серверы:

208.67.222.222
208.67.220.220

При этом тебе не нужно никакое другое дополнительное программное обеспечение. Просто настрой свою систему на использование этих DNS-серверов.

Но все равно остается проблема перехвата DNS-соединений. Да, ты уже обращаешься не к DNS провайдера, а к OpenDNS, но все еще можно перехватить пакеты и посмотреть, что в них. То есть при желании можно узнать, к каким узлам ты обращался.

Вот мы и подошли к DNSCrypt. Эта программулина позволяет зашифровать твое DNS соединение. Теперь твой провайдер (и все, кто между тобой и им) точно не узнает, какие сайты ты посещаешь! Еще раз повторюсь. Эта программа не замена Tor или VPN. По-прежнему остальные передаваемые тобой данные передаются без шифрования, если ты не используешь ни VPN, ни Tor. Программа шифрует только DNS трафик.

В КАЧЕСТВЕ ЗАКЛЮЧЕНИЯ

Статья получилась не очень большая, поскольку сама программа очень проста в использовании. Но она была бы неполной, если бы я не упомянул и о VPN. Если ты прочитал эту статью, тебя она заинтересовала, но ты еще не пользуешься услугами VPN-провайдера для шифрования своих данных, то самое время это сделать.
VPN-провайдер предоставит тебе безопасный туннель для передачи твоих данных, а DNSCrypt обеспечит защиту DNS-соединений. Конечно, услуги VPN провайдеров платны, но ведь за безопасность нужно платить?

Можно использовать, конечно, и Tor, но Tor работает относительно медленно, и это, как ни крути, не VPN - весь трафик «торифицировать» не получится. В любом случае (какой бы вариант ты ни выбрал) теперь твои DNS-соединения защищены. Осталось только определиться со средством шифрования трафика (если ты это еще не сделал).

Last updated by at Октябрь 30, 2016 .

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

Мир цензуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И как оно работает?

Для тестирования, в качестве прокси-сервера я арендовал дешевый 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 с его превью;
• jcgonzalez.com - упал, но 404 выдает быстро;
• minergate.com - 1м;
• vk.com - 23c, страницы с сообщениями по секунд 10 и больше, в зависимости от содержимого;
• linkedin.com - 40c;
• weather.com - не загрузился;

С таким интернетом жить уже можно, особенно, если мало альтернатив. Стеганографическая стойкость падает с повышением отношения шум/полезная информация, жертвовать или нет - решать не мне.
На этом считаю эксперимент завершенным. Исходники, бинарники, инструкции по применению и помощи находятся на гитхабе ниже. Если будут дополнительные вопросы - буду ждать в комментариях.

Last updated by at Январь 12, 2017 .

14.06.2017 | Владимир Хазов

Мировая статистика показывает, что доля шифрованного трафика сети Интернет уже превысила 50 %, и эта тенденция будет сохраняться. Получить SSL-сертификат для своего сайта или сервиса становится проще, и каждый владелец ресурса выбирает протокол HTTPS, защищая данные своих пользователей. Для операторов связи и интернет-провайдеров остро встает вопрос выбора способов классификации шифрованного трафика. О них мы и расскажем сегодня.

Почему растет доля шифрованного трафика?

Большую часть зашифрованного трафика генерируют такие крупные поставщики контента, как Facebook, YouTube, Netflix и другие. Их стремление перевести доступ к своим сервисам на протокол HTTPs вызвано глобальной тенденцией обеспечения конфиденциальности в Сети и защиты передаваемых данных.

Аналогично поступают и ведущие дата-центры мира: Yahoo, Google и Microsoft шифруют весь свой внутренний трафик, а также до 25 % трафика , используемого веб-приложениями, электронной почтой и облачными платформами.

Российские реалии немного отличаются от общемировых: примерно 40 % от всей полосы пропускания занимает P2P-трафик, на веб-доступ приходится еще 40 %, остальные 20 % – другие протоколы. Причем за последние 4 года доля HTTPs увеличилась в 2 раза (с 5–10 % до 15–20 %), что обусловлено переходом мировых поставщиков контента на SSL-шифрование (по данным аналитических исследований телекоммуникационной компании УралВЭС).

Отчет по полосе пропускания УралВЭС

Принцип работы HTTPs

HTTPs – это обычный HTTP, который работает с использованием шифрованных механизмов SSL и TLS. В процессе обмена между пользователем и удаленным узлом данные передаются в зашифрованном виде и не могут быть перехвачены и использованы третьими лицами.

Безопасность HTTPs. Изображение: yandex.ru

Принцип работы протокола SSL/TLS заключается в использовании общих секретных ключей. Устанавливая соединение по HTTPs, ваш ПК сначала с его помощью шифрует информацию, а затем передает ее в Интернет. Взломать или подобрать ключ практически невозможно, так как он сложный и длинный, но существует вероятность перехвата и подделки адреса отправителя, в результате чего получатель будет думать, что пакет пришел от вас, а не от злоумышленника. Таким способом перехвата пользуются для создания man-in-the-middle -атак, но их можно избежать благодаря использованию цифровых сертификатов для идентификации сервера.

Сертификат помогает подтвердить:

• Что абонент, которому он выдан, действительно существует.
• Он управляет сервером, который указан в сертификате.

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

Как классифицировать зашифрованный трафик?

Классификация зашифрованного трафика не предполагает его дешифрацию, информация, содержащаяся внутри пакетов, остается конфиденциальной и видна только пользователю и удаленному узлу. Эти методы предназначены для интернет-провайдеров и операторов связи, которым классификация помогает гибко управлять трафиком и обеспечивать более высокое качество предоставления услуг (QoS и QoE).

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

1. Классификация трафика, зашифрованного SSL/TLS (например, HTTPs)

Типовые протоколы : Google, Facebook, WhatsApp и т. п.

Метод классификации : определить имя сервиса в сертификате SSL/TLS (Common Name) или в Server Name Indication (SNI).

Точность : детерминированный метод – точность 100 %.

Ограничения : если SNI не появляется в начале процедуры «рукопожатия», то имя сервиса берется из сертификата SSL/TLS (Common Name), доступность которого появляется только после передачи 5-6 пакетов, что может вызывать небольшую задержку. В зависимости от поставщика контента один и тот же сертификат может использоваться для разных сервисов (таких как электронная почта, новости и другие).

Server Name Indication в процессе «рукопожатия»

Common Name в сертификате SSL

1. Классификация зашифрованного трафика P2P

Типовые протоколы : BitTorrent, MuTorrent, Vuze и т. п.

Метод классификации : определение IP-адресов известных p2p-пиров.

Во время сессии P2P фаза инициализации соединения не шифруется. На этом этапе возможна идентификация IP-адресов узлов (пиров). Весь трафик, идущий с этих адресов, классифицируется как P2P (например, bittorrent).

Точность : обычно выявляет до 90 % сеансов P2P.

Дополнительная информация : IP-адреса хранятся в L3-4-кэше фиксированного размера, наиболее часто используемые из них попадают в верхнюю часть списка.

1. Классификация трафика Skype

Метод классификации : поиск бинарных шаблонов (сигнатур) в потоке трафика.

Как правило, эти шаблоны находятся в первых 2-3 пакетах трафика.

Точность : обычно составляет 90–95 %.

Дополнительная информация : такой статистический метод поиска шаблонов используется для идентификации различных сервисов Skype, таких как голосовая передача, видео и чат. Этот метод использует комбинацию различных исследований трафика: джиттер, задержка, длина пакета, расстояние между пакетами и другие.

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

Платформа глубокого анализа трафика СКАТ DPI от компании VAS Experts позволяет идентифицировать зашифрованный трафик всеми описанными методами, а также имеет дополнительные способы, оптимизированные для российских операторов связи.

Безопасность (шифрование) трафика

• Информационная безопасность

Параллельно с развитием технологий защиты интернет-трафика от несанкционированного доступа развиваются и технологии перехвата защищенного трафика. Перехватить и изучить незашифрованный трафик пользователя уже давно не составляет труда даже для рядового юзера. Практически каждому известно слово «сниффер». Теоретически, защищенные SSL /TSL -соединения перехватить обычными средствами невозможно. Но так ли это?

На самом деле - не совсем так. Да, зашифрованный трафик теоретически невозможно расшифровать, хотя опять таки теоретически при очень большой необходимости и желании, и такой трафик можно расшифровать, подобрав ключ. Однако для этого нужны такие затраты ресурсов, что актуальность взлома сохраняется только, наверное, на правительственном или военном уровне:)

При работе по защищенному соединению (самый просто пример - ) весь трафик между взаимодействующими точками в сети шифруется на стороне отправителя и дешифруется на стороне получателя. Шифруется трафик, идущий в обоих направлениях. Для того, чтобы его зашифровать и расшифровать нужна пара ключей (ассиметричное шифрование). Публичный ключ служит для зашифрования и передается получателю данных, а приватный - для дешифрования, он остается у отправителя. Таким образом, узлы, между которыми устанавливается SSL-соединение, обмениваются публичными ключами. Далее, для повышения производительности формируется единый ключ, который пересылается уже в зашифрованном виде и используется как для шифрации, так и для дешифрации на обеих сторонах (симметричное шифрование).

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

Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.

Если пользователь принимает сертификат-подделку, то трафик будет идти по следующей схеме:

клиент <= SSL-соединение => сервер-прослушка <= SSL-соединение => сервер назначения

Т.е. промежуточный сервер будет получать весь ваш «защищенный» трафик в открытом виде. Стоит также заметить, что передача сертификата происходит в начале каждой сессии HTTPS.

В случае защищенного SSH при первом соединении с сервером на клиенте сохраняется ключ сервера, а на сервере - ключ клиента. Эти ключи передаются между данными клиентом-сервером только один раз, при первом подключении. Если в этом случае SSH-трафик попытаются перехватить, то и клиент, и сервер откажут в соединении из-за несоответствия ключей. Так как ключи можно перенести между клиентом и сервером обходным путем (по защищенному каналу или на внешнем носителе), этот способ соединения является относительно безопасным. Его могут лишь заблокировать, заставив пользователя работать в открытую.

Стоит отметить, что уже давно продаются так называемые «решения по информационной безопасности предприятия», которые перехватывают весь трафик, проходящий через офисный прокси-сервер, и «читают» его. Программы ищут наличие определенных фраз или информации определенного вида в потоке данных от браузеров, почтовых программ, ftp-клиентов, мессенджеров сотрудников офиса. Причем, эти программы умеют различать и обрабатывать правильно самые разные виды информационного взаимодействия с серверами. В том числе, они проверяют и защищенный SSL-трафик путем подмены сертификатов. С разработкой одной из таких систем я сталкивался почти непосредственно.

Но пути спасения от тотальной слежки есть. Через установленное SSH-соединение можно направлять любой нужный трафик, который с SSH-сервера будет уже в открытом виде идти на конечную точку. Этот способ называется SSH-туннелинг (tunneling). Так можно обезопасить прохождение трафика по незащищенному каналу, но имеет смысл такой подход только при наличии доверенного сервера с поднятым и настроенным на туннелинг SSH-демоном. Причем организовать это достаточно просто. SSH-клиент подключается к серверу, настраивается на прослушку любого данного порта на локальной машине. Этот клиент будет предоставлять услугу SOCKS5-прокси, т.е. его использование можно настроить в любом браузере, почтовых программах, IM-ах и т.д. Через SSH-туннель пакеты попадают на сервер, а с него уходят на целевой сервер. Схема получается следующая:

<== SSH-соединение ==> сервер <=> целевой сервер

Другой способ защиты трафика - VPN -канал. В использовании он проще и удобнее SSH-туннелинга, но в первичной установке и настройке сложнее. Основное удобство этого способа в том, что в программах не нужно прописывать прокси. А некоторый софт и вовсе прокси не поддерживает, следовательно только VPN и подойдет.

На практике есть два варианта работы. Первый - покупка VPN-акканута, который продается специально для этих целей (шифрование трафика по небезопасному каналу). В этом случае продаются обычно аккаунты, соединяться с которыми надо по протоколам PPTP (обычный VPN, который реализован, например, в Windows) или L2TP.

Второй вариант - покупка VDS-сервера (виртуальный выделенный сервер) с любым дистрибутивом линукса на борту и поднятие на нем VPN-сервера. VDS может быть российским или американским (только не забывайте про заокеанские пинги), дешевым (от $5) и слабым или дорогим и помощнее. На VDS ставят OpenVPN -сервер, а на компьютере поднимается OpenVPN-клиент. Для Windows есть даже гуишная версия клиента .

Если вы решите использовать вариант с OpenVPN, то есть например эта простая пошаговая инструкция по поднятию сервера (Debian). Установить клиента еще проще, особенно под Windows. Отметить стоит только один нюанс. Если весь трафик требуется пустить по созданному VPN-соединению, то требуется прописать default gateway на шлюз VPN (параметр redirect-gateway в конфиге клиента), а если только часть трафика (на определенные хосты), то можно прописать обычные статические маршруты на данные хосты (по IP; например, route add -p 81.25.32.25 10.7.0.1).

Для соединения OpenVPN обмен ключами происходит в ручном режиме, т.е. транспортировать их от сервера на клиент можно абсолютно безопасно.

Таким образом, SSH- и VPN-соединения могут практически полностью гарантировать безопасность вашего трафика при перемещении по незащищенному каналу. Единственная проблема, которая может возникнуть в этом случае, - это запрет на SSL-трафик на корпоративном файрволе. Если SSL-трафик разрешен хотябы на один любой порт (обычно дефолтный 443), то вы уже потенциально можете поднять и SSH-тонель, и VPN-соединение, настроив соответствующего демона на вашем VDS на этот порт.

Теги:

• internet
• security
• ssl