Latest revision as of 05:17, 21 May 2010 (edit) Leksey (Talk | contribs) (New page: * Установление соединения и его защита : Оригинал: [[tkabber:Между офлайном и онлайном|Перес...)

(No difference)

---

Latest revision as of 05:17, 21 May 2010

• Установление соединения и его защита

Оригинал: Пересылка файлов: теория (Tkabber Wiki).

Автор: Kostix и Bigote

Версия статьи: 21:49, 14 февраля 2009 ссылка

Лицензия: неизвестно (не указано в источнике)

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

Для самых маленьких[edit]

Здесь приведены "рекомендованные" настройки для типичного случая, под которым мы понимаем соединение с сервером jabber.ru.

Рассмотрим самый простой случай: вы подключены к интернету напрямую, безо всяких прокси, вместе с Ткаббером установлены все нужные и ненужные пакеты, перечисленные, например, тут. В этом случае на 95% подойдут следующие настройки:

• На вкладке "Соединение" окошка логина (которое вызывается по Ctrl-L) ничего отмечать не надо.
• На вкладке "Аутентификация" включить две галочки: "Использовать SASL для аутентификации" и "Разрешить механизм SASL X-GOOGLE-TOKEN". Строго говоря, вторая из них нужна для подключения к аккаунту на гугль-талке, но пусть уж будет.
• На вкладке "SSL & Сжатие" отметьте "Шифрование (STARTTLS)".
• Вот, в общем-то, всё. Должно работать. Если вдруг не работает, попробуйте на вкладке "Шифрование" сменить опцию на "Шифрование (Старый SSL)" или рискните "Открытый несжатый текст". Эту последнюю опцию следует пробовать лишь в самых крайних случаях. Если с ней подключиться удалось, следующий ваш шаг должен быть сделан в направлении настройки защищённого (шифрованного) соединения. Прямым ходом идите к нам в конференцию и просите помощи (дочитав перед этим статью до конца!) И ни в коем случае не злоупотребляйте опцией "Открытый текст". Тоже в качестве крайней меры можно попробовать и первую опцию про открытый текст на вкладке "Аутентификация" — с теми же оговорками.

Ветхий и Новый заветы XMPP[edit]

Настало время развеять один укоренившийся миф.

Принято считать, что XMPP ≈ Jabber. В принципе, так и есть: XMPP обратно совместим с Jabber, но и довольно серьёзные различия также имеют место. Большая, если не бо́льшая часть этих различий как раз приходится на механизм установки соединения с сервером.

Относительная сложность диалога логина в Ткаббере как раз отражает эти различия, причём (возможно, к неудовольствию новичков) — с сугубо технических позиций. Однако здесь мы попытаемся поставить всё на свои места. С другой стороны, мы покажем, что дёргать настройки приходится, как правило, только при переходе со "старого" сервера на "новый" и наоборот.

RFC #3920 назвает "старый Jabber" терминами "pre-XMPP" и "XMPP 0.9"; это, конечно, неофициальные наименования. Мы будем использовать термин "Jabber", ссылаясь на устаревшие версии протокола, и "XMPP", — ссылаясь на текущую, стандартную, версию.

Чтобы было понятнее "кто есть кто" и чего ожидать от конкретного сервера:

• jabberd 1.4 — Jabber сервер; кое-где всё ещё используется, но больше не развивается.
• jabberd2 — XMPP-сервер. Используется не очень часто.
• ejabberd — XMPP-сервер. Используется очень широко; в частности, jabber.org и jabber.ru работают на нём.

Канал связи клиент-сервер в Jabber/XMPP[edit]

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

Фактически, всё, здесь рассказанное, изложено в стандарте на протокол XMPP: RFC #3920. Здесь же мы попытаемся описать это всё попроще и на языке родных осин.

Концепции[edit]

Передача информации — смысл и цель соединения между XMPP-клиентом и XMPP-сервером. Это соединение представлено двумя XML-потоками: от к клиента к серверу и от сервера к клиенту. Однако, прежде чем такая передача станет возможной, нужно решить три проблемы:

• Клиент должен выяснить, с каким физическим компьютером в сети и каким способом он должен установить соединение.
• Сервер должен знать, что клиент — именно тот, за кого он себя выдаёт. Проще говоря, если с сервером хочет работать пользователь Вася, он должен подтвердить, что он именно Вася, а не Петя или Маша. Этот процесс называется аутентификацией потока ("stream authentication"). Обычно таким подтверждением является знание васиного пароля на сервере.
• Если не приняты какие либо специальные меры, информация в XMPP передаётся в открытом виде, то есть её можно "подслушивать" (англ. "to eavesdrop"), получая, к примеру, пароли к каким-либо ресурсам, которые наивный пользователь сообщил в чате другому пользователю. Также ни у одной из сторон TCP-канала связи нет гарантий того, что "та сторона" всё ещё "та": известно несколько атак на TCP/IP-соединение, позволяющих нарушить его целостность. Это называется влиянием на канал (англ. "tampering"). Специальные меры, решающие эти проблемы называются защитой потока (англ. "stream security").

Вместо термина "поток" мы также будем часто использовать термин "канал". Сути это не меняет.

XMPP чётко определяет стандартные способы защиты канала и аутентификации.

Кроме того, перед тем, как подключившийся клиент сможет начать обмен данными с сервером, должна произойти так называемая "привязка ресурса" ("resource binding") к созданному каналу — сервер должен закрепить за созданным каналом определённый "ресурс" клиента.

Куда и как подключаться?[edit]

Защита потока[edit]

Традиционно как в Jabber-, так и XMPP-серверах процедура защиты канала, если таковая производится, выполняется раньше, чем аутентификация. Это разумно, так как в случае успешного завершения процедуры установления защиты потока, протокол аутентификации пользователя будет надёжно защищён от атак.

SSL/TLS[edit]

Существует достаточно много протоколов для защиты потока связи в IP-сетях, однако наибольшее распространение получил протокол SSL (Secure Sockets Layer).

Именно SSL используется как в Jabber, так и в XMPP для защиты канала. Однако, используется несколько по-разному (об этом — ниже).

Также путаницу вносит то, что в SSL, первоначально разработанный Netscape, был стандартизован IETF; при этом IETF переименовала протокол в TLS (Transport Layer Security). TLS основан на "версии 3" протокола SSL (обычно она именуется "SSLv3") и отличается от последнего довольно слабо, из-за чего обычно термины "SSL" и "TLS" используются вместо друг друга. Это совершенно неверно с формальной точки зрения, и немного неверно — с технической, однако удобно для пользователя: можете считать, что это один и тот же протокол.

SSL реализует:

• Целостность передаваемых данных — гарантируется, что передаваемые данные не могут быть незаметно изменены.
• Конфиденциальнось передаваемых данных — данные могут шифроваться различными (в том числе весьма криптостойкими, например, AES) алгоритмами.
• Взаимное удостоверение сторон, создающих канал связи, в том, что они именно те, за кого себя выдают.

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

Сертификаты SSL/TLS[edit]

SSL использует сертификаты X.509.

Аутентификация пользователя[edit]

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

Технически клиент может доказать серверу, что знает правильный пароль, несколькими способами.

Самый простой — просто передать пароль, введённый пользователем, серверу "как есть", то есть в открытом виде. Это самый плохой способ с точки зрения защиты данных: если трафик между клиентом и сервером может прослушать третье лицо (это, к примеру, общий случай на сегменте сети Ethernet, повсеместно применяемой в офисах), оно получит готовые данные для использования учётной записи клиента (его "аккаунта") по своему усмотрению. Такой вид передачи данных (без защиты) называется "открытым" ("plain text"). Резюмируя простыми словами, такой пароль обязательно перехватит даже самый ленивый хакер — просто чтоб неповадно было.

Чуть более защищённый способ — закодировать пароль при передаче. Такой способ, к примеру, используется в ходе "простой" ("basic") аутентификации на HTTP-прокси серверах. Однако такой способ защищает пароль только от глаз смотрящего на распечатку сетевого трафика. Так как человек, желающий заполучить пароль, скорее всего знает, где именно он его ищет, он также знает, какой способ используется для шифровки и, соответственно, не будет иметь трудностей с расшифровкой. Таким образом, уровень защиты пароля в этом случае ненамного выше, чем у открытого текста, ибо спасает лишь от глупого или очень зелёного хакера.

Значительно более эффективны алгоритмы аутентификации, основанные на механизме "вызов-ответ" ("challenge-response"), позволяющие обойтись без передачи пароля между клиентом и сервером. Их идея в следующем:

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

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

Чаще всего для вычисления хэша применяют алгоритм MD5 (см. также материал в Википедии)¹.

Реализация в XMPP[edit]

Реализация в Jabber[edit]

Поддержка в Ткаббере[edit]

Подключение к XMPP-серверу: практика[edit]

Здесь подробно рассказано, что предпринять для подключения к XMPP-серверу в особо тяжёлых случаях (к примеру, параноидально настроенный прокси-сервер). Акцент сделан на подключение к jabber.ru.

"Стандартный" XMPP сервер[edit]

Итак, что можно сделать, если соединение с Вашим сервером через прокси не проходит:

• Попробуйте присоединиться на каждый из стандартных портов; возможно, какой-то из них будет работать (имейте в виду, что при выборе 5222 следует включать опцию "Шифрование (STARTTLS)", а при выборе 5223 — "Шифрование (старый SSL)".
• Проверьте, принимает ли ваш Jabber-сервер соединения на порт 443 (следует выбрать "старый SSL" в настройках).
• Если ничего не помогло, попробуйте использовать механизм HTTP-poll, если ваш сервер его поддерживает. Протокол HTTP-poll позволяет реализовать связь с сервером путём посылки серверу HTTP-запросов (стандартно — на порт 5280), что, в принципе, должно сделать возможной работу через любой прокси-сервер, кроме совсем уж параноидально настроенных.

Пользователи сервера jabber.ru имеют несколько дополнительных опций благодаря тому, что вокруг этого сервера построена дополнительная "обвязка":

• ssl.jabber.ru поддерживает соединения с шифрованием "старый SSL" на порт 443;
• allports.jabber.ru поддерживает соединения на любой порт с поддержкой протокола STARTTLS.

Эти имена хостов и порты следует вводить в поля "хост" и "порт", соответственно, настройки "Явно указать адрес и порт для подключения".

(Информацию про jabber.ru нечаянно сболтнул teo.)

Дополнительная информация про HTTP-poll:

Для того, чтобы подключиться к серверу по HTTP-poll, нужно знать URL для отправки HTTP-запросов. Есть два источника подобной информации:

• На веб-сайте сервера опубликованы настройки — просто впишите их себе.
• В идеале, сервер должен иметь специальную TXT-запись в DNS, содержащую информацию о HTTP-poll. Начиная с версии 0.9.9, Ткаббер способен сам выполнить соответствующий запрос, так что поле "URL для подключения" в настройках соединения по HTTP-poll можно оставить пустым (однако, см. ниже). Если у вас более старая версия Ткаббера, вы можете выполнить соответствующий запрос вручную и ввести полученный URL в настройки HTTP-poll. Запрос выполняется так:
  • Windows (в командной оболочке):

    nslookup "-set type=TXT" _xmppconnect.jabber.ru

  • Unix:

    dig +short _xmppconnect.jabber.ru txt

    или

    host -t txt _xmppconnect.jabber.ru

Понятно, что в случае сервера, отличного от jabber.ru, доменная часть "псевдо-имени хоста" _xmppconnect.jabber.ru должна быть другой (например, _xmppconnect.my.cool.server.org).

Эта команда должна вернуть строку, содержащую URL для подключения, например, для jabber.ru возвращается "_xmpp-client-httppoll=http://httppoll.jabber.ru". В настройках, соответственно, следует указать URL http://httppoll.jabber.ru. Естественно, для другого сервера URL будет другим.

Подробнее про "ручное общение" с DNS-серверами написано здесь.

Примечание:

для работы с TXT-записями в DNS Ткабберу требуется наличие в системе библиотеки tcllib версии 1.7 и выше, а для работы с SRV-записями — 1.8 и выше. Реально, значение имеет версия пакета dns в библиотеке tcllib: поддержка SRV-записей появилась в версии 1.2.1 пакета, поддержка TXT-записей — в версии 1.1.8, но имела баг, который был исправлен в версии 1.3.1. Узнать версию пакета dns, доступную Ткабберу, можно, выполнив в консоли Ткаббера (или в tclsh, wish, tckon) команду

package versions dns

(За информацию про DNS TXT-записи, о HTTP-poll и за разъяснение ситуации с версиями пакета dns — отдельное спасибо тиклевому хакеру Pat Thoyts.)

Серверы Google Talk[edit]

Подробно о подключении к серверам Google Talk рассказано здесь.

Примечания[edit]

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

SHA-1 тоже "готов"...