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

– Ты кто такой???
– Я новый русский.
– А я тогда кто?!


Предисловие

В первой части статьи мы рассуждали о Direct Connect в целом и обустраивали ADCs хаб.

Сегодня нам предстоит научиться использовать такой хаб по прямому назначению. Для этого мы поговорим об особенностях совместимых DC клиентов и подружим их с TLS.

Translate to English

В настройках каждого из них нужно будет обратить внимание на раздел Encryption, он же Security & certificates или Безопасность.

Излишне упоминать, что при использовании активного режима TCP порт для TLS также должен быть проброшен.

AirDC++

Могучий наследник легендарного fulDC++, самого первого мода оригинального клиента. Нагляден и адекватен.


Настройки AirDC++ для работы на ADCs хабе

Ключ и сертификат генерируются при первом запуске клиента (или по требованию) и валидны 360 дней.


TLS при соединении клиентов друг с другом может использоваться и на обычном ADC хабе, но, правда, с непредсказуемым результатом (см. предыдущую часть статьи).

Что для клиента есть hub with trusted certificate?

Как показали тесты, даже если скормить хабу настоящий, подписанный центром авторизации сертификат (да хотя бы от Let's Encrypt), для клиента он доверенным не будет.


[S] = Secure, [U] = Untrusted

Критерием доверия к ADCs хабу является совпадение самостоятельно полученного клиентом отпечатка сертификата c явно указанным в адресе хаба.

*** Connecting to adcs://babylon.aab21pro.org:412/?kp=SHA256/1QTHF6U3SDQPQKCTCG3ZYK4LQS322MIXI64GMAX7PXLGKYCYTJOQ…
*** TLS error: Keyprint mismatch
*** The keyprint in the address doesn't match the server certificate, use /allow to proceed with untrusted connection

Трогательно, но бесполезно, поскольку keyprint не будет вечно одним и тем же; значит, для массового использования он не годится.

Другим способом получения заветного [S] является сохранение сертификата хаба в специально предназначенную для этого папку (она обычно совпадает с той, в которой клиент хранит собственные «документы»). Сертификат, понятно, надо испрашивать у администратора хаба, и такая возможность реализована на dchublist.org.

DC++

Оригинальный NMDC/ADC клиент, самый непритязательный. Впрочем, безопасности его разработчики уделяют немало внимания.


Настройки DC++ для работы на ADCs хабе

Обратите внимание, это единственный клиент, в котором соответствующая галка переводит безопасные соединения в режим forced, а её снятие означает не запрет оных, а всего лишь разрешение обычных, причём всё это – строго на ADC хабах.

А что такое direct encrypted private message channels?

DC++, AirDC++ и, внезапно, SharikDC умеют отправлять личные сообщения друг другу по защищённому каналу, минуя хаб. Привет, Телеграм!..

FlylinkDC++

Самый противоречивый. Из коробки (вплоть до билда за номером 21975) полностью игнорирует безопасные соединения и разрешает только обычные.


AirDC++ vs. FlylinkDC++

Правильные же настройки должны установиться вместе с обновлением.


Настройки FlylinkDC++ для работы на ADCs хабе

EiskaltDC++


Настройки EiskaltDC++ для работы на ADCs хабе

Вероятно, в силу использования устаревшего ядра от DC++, не умеет работать с кейпринтами в адресе хаба. Зато – это единственный клиент, который может быть настроен на использование исключительно безопасных соединений независимо от протокола, на котором работает хаб.

ApexDC++


Настройки ApexDC++ для работы на ADCs хабе

Самый толерантный. Ориентируется на настройки безопасности удалённого клиента – поэтому наряду с безопасными будут получаться и обычные соединения (например, с ненастроенными FlylinkDC++).

Ровно ту же схему работы можно получить в AirDC++ и EiskaltDC++, если использовать опцию Включено, но не forced.

И да, ApexDC++ является лучшим вариантом для «горячей» замены напрочь устаревшего StrongDC++.

Кстати, о StrongDC++


Оптимальные настройки безопасности для StrongDC++

Сделайте доброе дело себе и другим, не заставляйте сбросившие поддержку TLS 1.0 клиенты пытаться безопасно соединяться с Вами – это всё равно не будет работать.

Эта же логика вполне применима к настройке любимого некоторыми GreylinkDC++.

Эпилог

В случае успешной установки соединения с использованием TLS (например, при скачивании файллиста) колонка Cipher или Шифр в окошке передач будет заполнена (в AirDC++ иначе, см. ниже)



Как видите, не без шероховатостей, но шифрование в DC имеет место быть и работает.

В третьей части статьи мы проведём полевые испытания и выясним, почему по некоторым полям с TLS лучше вовсе не ходить.

Комментарии 3

    0
    Добавил информацию для удостоверения «подлинности» хаба без явного использования кейпринта.
      0
      Добавил информацию по настройке EiskaltDC++.
        0
        От нечего делать исследовал поведение некоторых DC клиентов при стыкнутой галочке безопасных соединений – сюрпризы нашлись и здесь.

        AiDC++

        Выключено = только обычные
        Включено = разрешены небезопасные (дефолт)
        Форсированно = только безопасные

        FlylinkDC++

        Включено = разрешены небезопасные (дефолт)
        Выключено = только обычные

        DC++

        Включено: только безопасные (дефолт)
        Выключено: разрешены небезопасные

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое