В рамках проекта sslh (http://www.rutschle.net/tech/sslh.shtml) развивается мультиплексор ssl/ssh соединений, способный принимать соединения на одном порту и перебрасывать их в зависимости от типа протокола. Поддерживается широкий спектр протоколов, среди которых  HTTP, HTTPS, SSH, OpenVPN, tinc и XMPP. Наиболее востребованным применением sslh является обход межсетевых экранов, допускающих только ограниченное число открытых портов.

Например, запустив sslh за пределами межсетевого экрана на 443 порту, можно организовать работу SSH и любых других протоколов: соединение с внешней системы будет производиться на 443 порт, но пробрасываться на локальный 22 порт, при этом штатные HTTPS-запросы будут перебрасываться на localhost:443.

Для обеспечения работы такой схемы sslh следует запустить с опциями:

   sslh --user sslh --listen 192.168.10.15:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:443

где, "--user sslh" определяет пользователя, под которым следует запустить sslh;
"--listen 192.168.10.15:443" - IP и порт для приёма внешних соединений;
"--ssh 127.0.0.1:22" - IP и порт для проброса SSH
"--ssl 127.0.0.1:443" - IP и порт для проброса SHTTP

URL: http://linuxaria.com/pills/sslh-a-sslssh-multiplexer-for-lin...
Обсуждается: http://www.opennet.me/tips/info/2705.shtml

• Мультиплексирования ssl/ssh соединений через один 443 порт,Alex, 00:03 , 30-Июл-12
  • Мультиплексирования ssl/ssh соединений через один 443 порт,pavlinux, 01:25 , 30-Июл-12
  • Мультиплексирования ssl/ssh соединений через один 443 порт,Аноним, 13:34 , 31-Июл-12
• Мультиплексирования ssl/ssh соединений через один 443 порт,lnv, 19:09 , 30-Июл-12
  • Мультиплексирования ssl/ssh соединений через один 443 порт,pavlinux, 19:42 , 30-Июл-12
    • Мультиплексирования ssl/ssh соединений через один 443 порт,lnv, 00:12 , 31-Июл-12
    • Мультиплексирования ssl/ssh соединений через один 443 порт,Аноним, 13:35 , 31-Июл-12
      • Мультиплексирования ssl/ssh соединений через один 443 порт,pavlinux, 16:33 , 31-Июл-12
        • Мультиплексирования ssl/ssh соединений через один 443 порт,filosofem, 21:53 , 31-Июл-12
          • Мультиплексирования ssl/ssh соединений через один 443 порт,pavlinux, 01:17 , 01-Авг-12
            • Мультиплексирования ssl/ssh соединений через один 443 порт,Аноним, 23:40 , 03-Авг-12
              • Мультиплексирования ssl/ssh соединений через один 443 порт,Nas_tradamus, 11:53 , 04-Авг-12
              • Мультиплексирования ssl/ssh соединений через один 443 порт,pavlinux, 17:01 , 06-Авг-12
• Мультиплексирования ssl/ssh соединений через один 443 порт,Jokerjar, 18:33 , 31-Июл-12
• Мультиплексирования ssl/ssh соединений через один 443 порт,alp, 18:10 , 02-Авг-12
  • Мультиплексирования ssl/ssh соединений через один 443 порт,Иван Иванович Иванов, 02:21 , 10-Авг-12
• Мультиплексирования ssl/ssh соединений через один 443 порт,Nas_tradamus, 13:32 , 03-Авг-12
• Мультиплексирования ssl/ssh соединений через один 443 порт,Elhana, 02:21 , 14-Авг-12

Занимательно.
Насколько я понял - прежде всего для всевозможных хотспотов, где есть только 80 и 443. Только вопрос - заработает ли, если например метод connect запрещен?

Насчёт CONNECT не знаю, а с обрезанным проводом или выключенным компом, точно заработает.

> если например метод connect запрещен?

Тогда и https не заработает, внезапно.

Connect не запрещен обычно для https/443, не?

Как я понял, он хочет домой протянуть канал, через какого нить прорва.
К примеру на MTC/Стрим банят всё.  

Ну если только так.

> К примеру на MTC/Стрим банят всё.

Что, даже DNS? А то есть iodine и тому подобное еще :)
Капча согласна: 77770

А с каких пор клиенты обрабатывают ДНС-запросы?

Он про ДНС-туннелирование, когда трафик пакуется в риквесты и TXT записи.

Для поднятия днс-тунелля запрос все равно клиент должен отправить.  

И что? Половина провов услужливо резольвит адреса :). Клиент - отправляет. Днс запросы. И получает. Ответы. Улавливаешь к чему это ведет? Да, это тоже может быть транспортом, хоть и извращенским :)

> И что? Половина провов услужливо резольвит адреса :). Клиент - отправляет. Днс
> запросы. И получает. Ответы. Улавливаешь к чему это ведет? Да, это
> тоже может быть транспортом, хоть и извращенским :)

У меня за жизнь было где-то 5 провов и ни один не резолвил адреса. Лет 10 назад читал статью в хакере о том, как завернуть трафик в dns-запросы.

Вы явно не в тему. Я про то, кто инициирует соединение.
А для DNS-тунеля ваще отдельный сервак нужен.

Хм, я на сервере просто зеркалирую с помощью iptables SSH на 443 порт (можно просто настроить SSH на работу на этом порту). С работы коннекчусь на него нормально через цепочку прокси. Учитывая наличие SSH-туннеля, могу подключиться хоть чем и хоть куда. Profit!

А как логами быть? IP же будет локальный писаться.

1) логи самого sslh
2) логи iptables (--syn --state NEW)

На хабре на днях появлялась интересная статья на тему всех возможностей SSH. В том числе, там и это было.

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

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

Мои параноики вообще поставили https proxy от bluecoat (?), по сути MITM и режут/читают все.

На каждую хитрую жопу найдется свой болт на 18 и на каждый болт найдется своя жопа с лабиринтом.