Tkabber Wiki

Между офлайном и онлайном
Login

Между офлайном и онлайном

Материал из Tkabber Wiki

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

Содержание

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

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

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

(!) Сделать: развить

(!) Сделать: вынести в отдельную статью раздел фака "Не могу подключиться ... через прокси" и поставить отсюда ссылку на него

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

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

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

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

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

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

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

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

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

Концепции

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

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

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

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

(!) Сделать: расписать про ресурсы

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

Защита потока

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

SSL/TLS

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

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

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

SSL реализует:

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

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

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

(!) Сделать: развить тему

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

<hiddenman> какая-то китайка уже SHA-1
вслед за MD5 и прочим "поломала".
<ilyak> hiddenman: И теперь сидит, как дура, без SHA-1

Цитата с башорга

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

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

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

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

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

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

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

Реализация в XMPP

(!) Сделать: написать

Реализация в Jabber

(!) Сделать: написать

Поддержка в Ткаббере

(!) Сделать: написать

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

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

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

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

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

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

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

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

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

Понятно, что в случае сервера, отличного от 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

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

Примечания

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

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

(!) Сделать: порыть...