Туннелирование TCP через веб-прокси часть 2: HTTPort3+HTTHost1=?

Старые читатели нашей газеты наверняка помнят материал "Туннелирование TCP через веб-прокси"
(http://www.nestor.minsk.by/sr/sr0006/sr00607.html), описывавший упомянутую в заголовке технологию и ее практическую реализацию в продукте HTTPort. Технология эта предназначена для обхождения юзерами прокси-файрволлов, регулирующих поведение в Интернете, и по сему — вызвала широкий общественный резонанс, причем как со стороны зерской, так и админской общественности. Админы — народ вредный и пугливый — сделали все возможное для запрещения использования TCP-туннелирования на своих прокси-серверах. Однако и технологический прогресс не стоит на месте — в конце прошлого года автор HTTPort порадовал мир новым релизом теперь уже семейства продуктов HTT — HTTPort2 и HTTHost, которые, работая в паре, позволяют пользователю обойти ограничения ЛЮБОГО корпоративного веб-прокси! Правда, ограничения демо-версий этих продуктов и неопределенность с условиями распространения изрядно подгадили в деле популяризации этого решения — событие выхода HTTPort2 осталось в тени. И вот не так давно разработчик и продавец этого ПО, разобравшись со своими проблемами и беспокойствами, порадовали выходом HTTPort 3 и HTTHost 1.4 — нормальных, полнофункциональных, удобных в использовании, доступных для скачивания продуктов.

Но для начала, для тех, кто не читал предыдущего материала о HTTPort и от лени или иной напасти не собирается пойти на наш веб почитать -

краткое содержание предыдущей серии
Туннелирование TCP через веб-прокси представляет собой способ использования HTTP-метода CONNECT для организации туннеля между клиентом (по одну сторону прокси-сервера) и неким демоном (сервером), обеспечивающим сервис по протоколу TCP — например IRC, SMTP, POP3, HTTP и др. Суть метода тривиальна: когда прокси-сервер получает запрос вида CONNECT host:port HTTP/1.x, он открывает на указанные в запросе хост:порт исходящее соединение, и после установления соединения начинает отдавать на сокет со стороны клиента данные в нетронутом виде, то бишь все содержимое поля "данные" TCP-сегмента. Организовывается туннель. Теперь и клиент, позабыв про HTTP-запросы, кидает в новообразовавшийся туннель сырым TCP-материалом. Ну и так далее.

Рис 1. Схема взаимодействия ПО через туннель, организованный HTTPort 1. Надписи над стрелками есть ни что иное, как перечень инкапсулируемых протоколов, начиная с транспортного уровня. Внимание, пустыми кружками обозначаются логические порты TCP, а не физические интерфейсы.

HTTPort1 был устроен таким образом (см. Рис. 1): с одной стороны это туннелирующий клиент (далеко не во всех интернет-приложениях вы найдете в прокси-настройках метод CONNECT), а с другой стороны — несколько,условно говоря, отображаемых портов, каждый из которых "смотрит" в нужный туннель. Например, чтобы ходить таким образом на IRC, создаем соответствие: Local Port 6667 — Remote Host irc.dal.net — Remote Port 6667. В IRC-клиенте прописываем в качестве сервера 127.0.0.1 порт 6667, а HTTPort через выбранный вами прокси-сервер организовывает туннель, вот так например:

клиент:
CONNECT irc.dal.net:6667 HTTP/1.0
<пустая строка>
прокси-сервер:
HTTP/1.0 200 Connection established
Proxy-agent: WinRoute Pro/4.1
<пустая строка>
<далее начинается туннелирование данных, относящихся к IRC>

Затем полученные из туннеля сырые данные передаются вашему mIRC'у через отображаемый порт. Все очень и очень простенько. На рисунке 1 представлена полная схема взаимодействия через HTTPort 1.
Однако, если смотреть на мир глазами юзера, видятся некоторые неприятненькие проблеммки. Во-первых, поскольку метод CONNECT изначально придумывался для туннелирования SSL, большинство администраторов ограничивают использования туннелирования именно этим протоколом либо запрещают CONNECT вовсе. Поэтому, если единственное окно в мир для юзера — порт веб-прокси на корпоративном файрволле без поддержки туннелирования или с ограниченной поддержкой этого метода (например, только для) SSL, про IRC, "некорпоративный" SMTP и прочие приятные вещи придется позабыть....То есть пришлось бы позабыть, если бы не появились HTTPort2/HTTHost.

Рис 2. Схема работы через туннель, создаваемый парой HTTPort-HTTHost. 
Все примечания к Рис.1 справедливы и здесь.

Рис. 3. Условная схема HTTPort 3. Внешне напоминает схемы HTTPort 1 и 2 (Рис. 1 и 2), слитые воедино, с добавленной "прослойкой" в виде модуля шифрования и "гарниром" в виде SOCKS

что нового?
А все новое! В отличие от первой версии, где для взаимодействия по TCP использовался "сомнительный" метод CONNECT, здесь мы можем пользоватсья "благонадежным" GET, просачиваясь через самый-пресамый навороченный файрволл.
В общем виде схема представлена на рис 2: (опять нарисуем для IRC, хотя справедливо и для многих других базирующихся на TCP протоколов)
Как видим, со стороны клиента все осталось прежним — отображаемые порты, указывающие на некие удаленные сервисы. Однако на этом схожесть и заканчивается. "Туннель" организовывается между HTTPort2, работающим на пользовательской машине, и серверной частью — HTTHost, расположенной по другую сторону файрволла. Между ними через корпоративный прокси идет обмен закодированными данными: от клиента исходят запросы вида GET http://www.host-gde-sidit-htthost.com/Vgtktk?DUUHnIl6uIDLEjNzCvkVFXjTOKiiB9kVY3wvOyKdSgW&Qd6XlbHiRNjUZ6tOxLvOaI2s, а в ответ "выплевываются" упопомрачительные "веб-страницы" — заголовки HTTP, <html><head>, а внутри "типа тэги и типа текст". Ну и в хвосте, как водится, </head></html>— все как положено. Целиком пакеты — вариант запроса и замечательный гипертекст в ответ — вы можете лицезреть на скриншотах (см. Рис. 4 и 5). 

Рис. 4. Портрет пакета, несущего в себе GET-запрос к HTTHost'у. Как видно из дампа, тестовый HTTHost расположен по адресу 192.168.99.11 и слушает порт 81.

Рис. 5. А это "наш ответ Чемберлену" — HTTHost передает HTTPort'у информацию, замаскированную под веб-страницу. Вот, оказывается, какие в HTML'е есть дивные тэги. Учитесь, вебмастеры;))

Рис. 6. А так ваша активность представляется глазу системного администратора. В нашем примере используется метод Remote Host (TCP-over-HTTP) через публичный HTTHost.

То, как ваша активность видна системному администратору, просматривающему логи прокси-сервера, представлено на Рис. 6.
Как вы могли догадаться, данные в запросе GET и "веб-страницы" в ответах — ни что иное, как зашифрованные команды на открытие-закрытие соединений и прочая служебная информация плюс собственно данные протоколов более высокого уровня. По сути, изобретен новый, недокументированнный протокол, который можно назвать "инкапсуляция TCP в HTTP" или TCP-over-HTTP. Расшифровывая эти кодированные строки, HTTHost с одной стороны поддерживает TCP-сессию с удаленным сервером от имени клиента, HTTPort с другой стороны держит TCP-сессию с клиентом через отображаемый порт. 
Поскольку, как было сказано выше, протокол этот является закрытым (почему — см. ниже), далеко не все аспекты его функционирования доступны даже для особо любознательного, даже вооруженного сниффером и winsock-debugger'ом глаза. Поэтому считаю возможным привести на страницах газеты краткое (и сумбурное) описание своего детища, сделанное автором проекта Дмитрием Двойниковым в ходе нашей с ним электронной переписки:
Если вкратце — то так примерно: HTTHost — это по сути веб-сервер. Он принимает HTTP-запросы. Только вместо предоставления по этим запросам файлов или выполнения скриптов, он выполняет некие странные манипуляции — открывает и закрывает TCP/IP соединения, передает и принимает через них данные. 
Технически это все очевидно называется инкапсуляцией TCP/IP в HTTP.

Сейчас поддерживается 3 (суб)протокола:
1. connect, send, receive, disconnect — это собссно TCP/IP
2. server_variables — удаленный мониторинг, параметр CentralIP отвечает за адрес, с которого разрешен мониторинг.
Мониторинг включает параметры типа — connections, data_in, data_out, и т.д. Любителям троянов можно не беспокоиться.
3. oob — несколько команд для получения внедренных (Out Of Band) данных. Используется для пересылки баннеров.
Естественно, введены тайм-ауты и прочие константы, так что ожидать бесконечной скорости от инкапсулированной таким образом коннекции не стоит.
11к/сек — предел. Откуда это пошло: клиент за один GET- запрос не получает больше, чем размер внутр. буфера HTTHost. Буфер — 16к, BASE64-кодирование, используемое при пересылке, дает коэфициент 3/4. 3/4 * 16к = 12к, минус служебный заголовок = 11к. HTTPort не посылает GET запрос чаще 1 раза в секунду.
Вот и все. Это ограничение скорости на прием. На передачу — примерно 2к/сек по тем же причинам. Практически еще свои задержки вносит прокси.
Еще одна идея — это passthrough фича, не знаю как перевести. Если HTTHost получает HTTP запрос, который он не знает, как обработать, он его прозрачно (на уровне TCP/IP) переправляет другому HTTP серверу. Таким образом можно в браузере набрать http://www.htthost-running-site.com/ а в ответ получить, скажем, Yahoo:)
Еще есть фильтры — все данные, направляемые на определенные адреса/порты, проходят через DLL-ки, которые могут эти данные пропускать/запрещать и править на лету. Так, например, вставлен фильтр smtp.dll на все тунеллируемые порты 25. А сам фильтр добавляет к пролетающему сообщению поле Received By:... как и полагается.
Вот, собственно, и все дела.

О причинах закрытости протокола:
...Протокол мне не жалко, есть одна деталь — прога-то должна прятаться.Мало админов, которые могут покурочить winsock-дебаггером, а потом попытаться кустомизировать прокси, чтобы он данный конкретный протокол не пропускал. А со спецификации списать — запросто.
Дальше, однако, начинались сплошные неприятности...
На момент выхода вторых версий продуктов с официального сайта проекта можно было слить лишь демо-версии HTTPort2 и HTTHost. 
Обе эти демки отличались редкостным зловредством в плане демо-ограничений, а именно: предлагалось установить и клиент, и сервер на одну машину. Соответсвенно, все самое интересное "движение" проходило через localhost, поскольку HTTHost-demo биндился на 127.0.0.1:80, а HTTPort-demo мог, соответсвенно, только с этим соединяться. 

Причем что самое смешное: суть технологии — для чего, собственно писались данные продукты — обхождение файрволла, но при этом мы даже не могли протестировать продукты с каким-нибудь реальным проксиком, поскольку в демо-версии поле ввода рядом с меткой "HTTP proxy you need to bypass" попросту отсутствует!
Разьяснения и FAQ на сайте (даже раздел "expert explanation") обилием информации не отличались, но самое интересное: нигде нет ни цен, ни условий покупки, ни ссылки на то, что продукт бесплатный... 
Вообще на тот мемент при взгляде на сайт совершенно было непонятно, какого черта продукт написали и как его собираются распространять.
"Если вам интересно узнать больше о HTTHost или вы хотите хостить его у себя для ради поддержки свободы и анонимности пользователей Интернет, пожалуйста свяжитесь с нами." Конечно интересно! Первым (и последним) "проконтактиованным" в списке числится знакомый уже вам Дмитрий Двойников. Вот что он нам поведал:

Что касается распространения — я распространением не занимаюсь, это дело Technology Networks. Пишите на httport@technetva.com желательно с конкретными вопросами. Можно купить SDK, для того он собственно и сделан. Можно наверное купить и исходники, но это я подозреваю дорого будет:)
Хостить его можно даром, при условии, что вы — компания, и у вас быстрый канал. За баннера пока ничего не берется, но баннера не должны быть порно и т.д. (мониторинг). Сеть хостов — одна. Нет такого, чтобы — я тут хочу у приятеля поставить хост, и через него с работы лазить. Для всех. Можно наверное обсуждать и приятеля, но с TechNet и за денежку. Видите, как все размыто... Можно так... А можно — этак... Зависит от того, что надо.
После такого "неконкретного" ответа контактировать напрочь расхотелось, и, букрнув в ответ что-то вроде "ну вас.. сами разберемся", ваша покорная слуга ушла в глубокое подполье...
... Прошло почти 3 месяца...

что мы имеем на сегодняшний день
Уж не знаю, повлияли ли мои препирания с разработчиком посредством электронной почтны на ход мысли хозяев проекта, или, возможно, таких "недовольных" стало прибывать и количество флейма переросло в качество, но тем не менее за прошедшие после инцидента 3 месяца произошли следующие революционные изменения в "политике партии и правительства": вышли новые версии обоих продуктов, убрано большинство демо-ограничений, обе описанные выше технологии слились в одном проекте. Это вкратце. Теперь подробности.
HTTPort 3.S1
Наконец-то нам предложена для скачивания полнофункциональная и бесплатная версия продукта, который теперь совмещает в себе оба описанные выше методы туннелирования: CONNECT и TCP-over-HTTP. С первым вам все должно быть понятно — никаких изменений по стравнению с HTTPort 1 не произошло. А вот инкапсулирование в GET-запросы, которым нас слегка подразнили во второй версии продукта, теперь работает на полную катушку.
У вас есть следующие варианты: использовать публичный HTTHost (программа подберет вам его по своему собственному разумению) или разместить за пределами вашей зафайрволенной сети свой персональный HTTHost. Подробней о хостах речь пойдет чуть-чуть попозже.
Прекрасная фича в новом семействе продуктов — встроенный SOCKS. Теперь приложения, для работы которых недостаточно одного отображаемого порта, как, например, ICQ, смогут работать через SOCKS, обращаясь на 127.0.0.1:1080. Добавлена также возможность шифрования данных — RSA при обмене ключами и Blowfish для передачи данных — что, впрочем, кажется мне излиншим, хотя... как знать. На Рис. 3 представлена условная схема нового HTTPort.
Конфигурирование продукта тривиально, но помня, что у некоторых читателей возникали вопросы с настройкой первой версии HTTPort, приведу краткий HOWTO. Всего-то и делов:
1. Вписать в поле "HTTP proxy you need to bypass" адрес и порт вашего корпоративного прокси-сервера.
2. При необходимости добавить сведения по авторизации на прокси.
3. Выбрать метод обхода прокси (bypass mode): SSL (CONNECT) — это то, что мы имели в первой версии HTTPort, Remote Host — то, о чем шла речь в описании второй версии продукта (оно же TCP-over-HTTP) или Auto — пробует сначала первое, при неудаче — второе.
4. Для режима Remote Host — вписать адрес и порт вашего персонального HTTPhost (см. ниже) или оставить соответствующее поле пустым для использования публичного сервера.
5. В разделе "Port Mapping" — завести нужное количество отображаемых портов для каждого сервиса, которым вы будете пользоваться через HTTPort. Ваши клиенты настроить таким образом, чтобы они соединялись с локальным сокетом дабы попасть туда, куда указывает отображаемый порт. В этом же разделе включается встроенный SOCKS-модуль.
Вот и все: жмите "Старт" и наслаждайтесь анонимностью и обилием интернет-сервисов.

HTTHost 1.4.1
На сегодняшний день у вас появилось аж две альтернативы использования HTT-Host в различных целях.
1. Если у ваших друзей, партнеров, знакомых есть хост за пределами вашей сети, защищаемой файрволлом и есть желание (возможность) выделить какую-то часть полосы пропускания под ваш "контрабандный" трафик — вам повезло: скачивайте бесплатный для персонального некоммерческого использования HTTHost PERSONAL DEMO (далее в примерах имеем в виду версию 1.4.1), устанавливайте и вперед на свободу, всем врагам назло!
Кратко пробежимся по конфигурационным опциям.
Bind To IP — адрес интерфейса, на который "садится" HTTHost. 0.0.0.0 — сесть на все имеющиеся в наличии интерфейсы.
Port — номер порта, который слушает HTTHost. Разумеется, наилучшим с точки зрения "невинности" будет 80-й.
Central IP — счастливых обладателей персональной версии сервера это не касается.
Bind SOCKS to IP — на какой интерфейс вешается встроенный SOCKS-сервер.
Personal password — при задании пароля, только "свой" клиент сможет использовать этот сервер.
Passthrough — то, о чем нам пытался рассказать Дмитрий Двойников в письме (см. выше). Эту фичу на русский язык можно перевести как "Прикидываемся валенком". Если она включена, все "левые", не понятные серверу запросы будут редиректиться на какой-то благонадежный хост/порт, например на www.lib.ru — типа у нас тут не HTTHost, а зеркало библиотеки Мошкова:)
Host name or IP — имя или цифровой адрес хоста, на который пойдет редирект.
Port — соответственно, порт на который редиректить.
Max. local buffer — размер локального буффера, по дефолту (и рекомендовано разработчиком) — 32К. Можно поставить и больше, возможно "зашуршит" чуть побыстрее, а может и нет:)
Timeouts — три вида таймаутов (разработчик забыл указать, что каждый из них обозначает). Для самых быстрых каналов — 1:1:1, для самых медленных — 2:4:8.
Жмем Apply и смотрим в окно статистики — ждем прихода клиента:)
Ах да, ну не может эта компания обойтись без ограничений демо-версий: максимум 8 соединений! Безобразие...
2. Если у вас более-менее приличный канал в Интернет (скажем, более 1 Мбит/с), сервер под управлением Windows NT/2000, скажем, PIII450/256, ваш узел не задействует ширину канала, например ваш веб-сайт еще совсем новый и пока не популярный, да и вообще если вы человек добрый и отзывчивый, вы можете стать членом публичной сети HTTHost'ов и внести свою лепту в защиту униженных и оскорбленных от произвола системных и сетевых администраторов, руководителей предприятий и т.д. А что нам за это будет кроме благодарности потомков? — спросите вы. Резонный вопрос:)
Вам за это будет возможность крутить свои (или чужие) баннеры на подключаемых к вам HTTPort-клиентах. Количество показываемых баннеров вычисляется по следующей простой формуле: за каждые 200К, которые клиент перекачивает через ваш HTTHost он получает в награду один баннер размером в 10К. Я только одного понять не могу: где же это в интерфейсе HTTPort 3 место, где кино (читай — баннеры) крутить будут? Наверное, не моего это дамского ума дело, ну да и бог с ними...:)

Alice D. Saemon
alice@nestor.minsk.by
обсуждение статьи