Pull to refresh

Шифрование трафика в Direct Connect, ч. 1

Reading time 4 min
Views 5.4K
Он же сказал им: цари господствуют над народами, и владеющие ими благодетелями называются, а вы не так: но кто из вас больше, будь как меньший, и начальствующий — как служащий. Лк. 22:25,26

История


Грешить Интернетом я начал с 2004 года, а соблазном на первых порах выступила местная локальная сеть. Точнее, программа под названием DC++ 0.401, магическим образом дававшая доступ к файлам, которыми делились другие абоненты той же локалки. Для этого нужно было подключиться к одному или нескольким узлам файлообменной сети, называемым хабами. Сами хабы держали на своих компьютерах местные энтузиасты.

«DC++» это название клиента. Протокол называется «Direct Connect». DC хабы. DC клиенты.

В этом была своя прелесть. Вот ты вне сети, а вот уже и внутри, среди людей, совершивших примерно те же действия, что и ты ранее. Удивительно, правда?

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


Тёплый ламповый DC++ v. 0.401

В-общем, DC с его простыми функциями общения и обмена файлами с успехом служило социальной сетью тех времён. И человеческое лицо по ту сторону экрана проглядывало настолько, насколько ты сам хотел его увидеть.

Прошли годы. Локальные хабы сдулись и издохли. Под натиском Фейсбука, ВКонтакте и торрента DC съёжилось до менее чем пяти сотен публичных хабов на старом NMDC протоколе и десятка (sic!) на протоколе Advanced Direct Connect.

Начало


Как уважаемые читатели уже знают, весь трафик россиян сохраняется до поры до времени. Дарить его в открытом виде — негигиенично, но именно это делают пользователи Direct Connect.

Итак, что требуется? Во-первых, шифровать общение DC клиента с хабом. Во-вторых, шифровать общение клиентов между собой.

И вот тут начинаются проблемы на всех уровнях этой простой и столь похожей на человеческое общество цифровой иерархии.

Хабы


Внезапно, подходящих хабов не обнаруживается. На старом NMDC протоколе их нет физически. ADCs же хабы существуют примерно с 2008 года, но погоды не делают, ибо так и остались малютками. Стало быть, такой ресурс придётся развернуть самостоятельно из уже существующего ADC хаба.

Клиенты


Программная поддержка TLS в DC клиентах есть уже давно, но, поскольку не было кейсов её применения, в этот раздел настроек тоже никто особо не заглядывал. А зря!

Перевести существующий ADC хаб на шифрование несложно. Сгенерировать самоподписанный сертификат, скормить его движку, выбрать «политику» TLS.

Но дело в том, что безопасное соединение с хабом устанавливается при использовании ссылки вида adcs://hub.address.com:port

Настройка же «политики» TLS состоит в том, чтобы или одобрять обычные соединения (то есть переход по ссылке вида adc://hub.address.com:port), или перенаправлять такого пользователя куда-нибудь (например, на «правильный» адрес).

tls_private_key="/etc/uhub/babylon.aab21pro.org.key"
tls_certificate="/etc/uhub/babylon.aab21pro.org.crt"

tls_enable=yes
tls_require=yes
tls_require_redirect_addr=adcs://babylon.aab21pro.org:412
Пример конфигурации TLS для uHub

Первый вариант оставляет возможность подключения к хабу пользователей с клиентами, которые не умеют TLS версии выше 1.0 (или вообще не умеют), что создаст проблемы; а второй обещает резкое падение посещаемости.
*** Connecting to adcs://babylon.aab21pro.org:412…
*** SSL Error 1: tlsv1 alert protocol version
Такое сообщение при попытке соединения с ADCs хабом отображает клиент, умеющий только TLS v.1.0

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

Админы


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

Администраторам и владельцам крупных DC хабов на данный момент интересно только количество пользователей онлайн и что с этого можно поиметь. Пользователи покупаются и продаются; отсутствует культура взаимодействия между админами и пользователями, отсутствует сообщество. Отсутствует, если хотите, мораль, вместе с ней этика и понятие нормы, а возникающие проблемы решаются по понятиям. А Вы помните буквальный перевод слова server?..

Вот и получается феодальная раздробленность. Выгоднее (для кого?) оказывается разрешать всё всем (например, использовать устаревшие 10 и более лет назад клиенты с известными уязвимостями), чем выступать гарантом чего бы то ни было.

Пользователи


Что владельцы хабов сделали наверняка — так это задолбали замучали юзеров спамом с требованием зайти куда-то или зачем-то зарегистрироваться вместо распространения внятных инструкций в случае наступления типичных ситуаций.

Не добавила в своё время DC популярности и необходимость проброса портов на роутере и знание «качества» своего IP-адреса. Процедура нетрудная, но по сей день вызывающая проблемы.

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

Итоги


Мы рассмотрели теорию и проблемы перевода уютного файлообмена в рамках Direct Connect на использование современного шифрования, необходимого в наши дни. Как видите, для этого пришлось указать на изъяны взаимодействия юзер <=> программа-клиент <=> хаб <=> администратор и придумать его заново.

Во второй части статьи планируется рассмотреть практику выбора и настройки DC клиента для работы на ADCs хабе.
Tags:
Hubs:
+20
Comments 17
Comments Comments 17

Articles