Arcane Lore

Днес новината е OpenAIM. С две думи — AOL публикуват спецификациите на протокола Oscar, на който се базират системите за моментни съобщения ICQ и AIM. Съвсем видимо в обявлението и в новия сайт на проекта се набляга на понятието “отворен код”. Може би засега няма да освобождават програмен код, но всъщност нямат и нужда — важното е, че от днес вече съвсем официално ще може да се правят клиенти за мрежата на ICQ/AIM, които да работят. Досега се правеха хакове и отгатвания на протокола. От днес той е публично достъпен.

Лично аз очаквах да направят крачка към джабер-федерацията. За мен това щеше да е правилинят ход. Не само, че XMPP е стандартизираният протокол за такива неща, ами и след дочулите се наскоро слухове, че от AOL експериментират с джабър-сървър, и нагласата сред общността на XMPP и на свободния софтуер като цяло беше станала поне с малко по-положителна.

Някои ще кажат, че отварянето на протокола Oscar е добра новина. Официално заявената поддръжка на странични свободни проекти, като библиотеката Purple (използвана в Pidgin и други), обещаният примерен програмен код и пълната документация на протокола и различните видове имплементации (за уеб, с флаш и т.н.) — всичко това изглежда много добре, несъмнено… Но все пак е леко подъл ход. Личи си, че е от принудата на обстоятелствата, от засега относително малкия, но все по-осезаем натиск от XMPP-федерацията от сървъри. Но все пак е подъл — защото не е нужно да се правят такива опити да се налага втори протокол.

Oscar можеше да продължи да живее в среда на XMPP — като даде свежи и различни идеи за развитието му. Нямам представа дали Oscar е толкова различен от XMPP, толкова принципно отдалечен, че да не може да се намери някаква средна линия. Не зная, защото не съм чел в подробности още — както казах, всичко това е развитие от днешния ден.

Ще чета — темата за XMPP и развитията около него е сред основните ми тук.

Това, което се разбира от прима виста е, че AOL явно са започнали да го закъсват откъм icq-реклами. Може би защото много хора по света ползват клиенти за ICQ, които не показват реклами. Както някои от вас може би знаят, официалният клиент показва постоянно в каре в прозореца за съобщения автоматични реклами от съръврите на ICQ. Може би има начини това да се спира, навремето се блокираха в защитните стени определени адреси на рекламните сървъри, може сега да има и други начини — не зная, но не в това е въпросът, идеята е, че icq-услугата в голяма част се издържа от тези реклами.

Сега, когато всеки ще може да седне и да напише свой си клиент за icq (да не го превъзнасяме — от години всеки може да напише свой си клиент за нещо много по-яко, именно XMPP), съвсем нормално е доста от тези разработчици да не включват рекламната част. Но от друга страна може да има други, които да правят клиенти, в които основното да са точно рекламите и да се издържат от някакво рекламно партньорство с AIM.

Възможностите са всякакви. Всъщност принципно може и нищо да не излезе — има много услуги, които публикуват своите API, но малко са успешните. Има и много публикувани протоколи, но малко от тях са разпространени и стандартизирани. Новината идва дни след като ISO гласува отново против приемането на MS OOXML, още един такъв пример. Така че само публикуването на протокола и дори заявеното желание да се работи с общността на F/LOSS не значи много.

Надявам се всичко това всъщност да послужи като още един катализатор на процесите и идеите в XMPP/Jabber. Има много неща, които са подготвени от толкова много време, но се внедряват внимателно, разбирай бавно. Пренос на глас и образ, история на разговорите на сървъра, различни начини за идентификация пред сървъра (например с OpenID) и т.н. Самата джабер-федерация носи своите си проблеми, например разпределена свързаност, но в същото време — концентрирана само в един сървър идентичност. При отпадане на сървъра от мрежата идентичността става недостъпна. Има идеи за федериране на идентичностите с всичките им прилежащи данни, тогава въпросът за сигурността и поверителността става по-сложен.

Но това е съвсем встрани от OpenAIM, защото Oscar, макар и публикуван вече, не дава засега начин за федериране на услугата. Тоест за да говоря с някого от ICQ или AIM, пак ще ми трябва идентичност, регистрирана на техния сървър и ще ми трябва и клиент, говорещ техния протокол.

На фона на слуховете за изпробване на XMPP от AOL тази новина наистина ми стои някак сиво… И все пак — честито на всички използващи ICQ и AIM! Най-малкото поне едно е сигурно — вече няма да спират Miranda, Gaim/Pidgin, mICQ и подобни при всяка промяна на протокола. Защото ще знаят за промяната и тя вече ще е подготвена в кода им.

Като си помислим… и това е нещо ;)

Остават Yahoo с YIM и Microsoft с MSN messenger. Всъщност не — за вторите е малко вероятно да отворят протокола, камо ли да се федерират с XMPP. Яху пък хем ритат да се оттласнат от предложението на Майкрософт, хем така и така вече използват XMPP за моментните съобщения в мрежата си в Y! Live. Остава да “очакваме включване”.

Колко много усилия да си запазиш своя си протокол и да пускаш реклами на хората. В дни, когато масово рекламите се филтрират или избягват. И толкова шум, толкова усилия на вятъра при условие, че има работеща свободна алтернатива с критична маса потребители. От федериране с джабер AOL само ще спечели, но не — друго си е да си отделно и наобратно.

Но ще видим — както казах, не съм чел в подробности още, а и не се знае как ще се развият нещата. Все пак честит OpenAIM!

Да, звучи малко невероятно, може би дори твърде хубаво, за да е истина. Но все пак си е вярно — ICQ (тоест AOL, значи не само ICQ, а и AIM може би в скоро време) вече изпробват джабер-шлюз към мрежата си. Това значи, че най-обикновен джабер-потребител ще може да се свързва с “черната кутия”, каквато до днес беше icq. При това да се свързва пряко, без посредничеството на джабер-транспортите, с които досега ставаше връзката с целия куп собственически или остарели протоколи и други измишльотини.

Аз се радвам, защото имам един стар айсикю-номер, от който дълго време не мога да се отърва, колкото и да се опитвам, колкото и да обяснявам на познатите ми защо трябва да се ползва XMPP. В най-“добрите” дни на това отказване свивах списъка с айсикю-контакти до двама-трима, които просто не мога да изтрия, защото ползват само айсикю. Свързвах се само през транспорти (преди на jabber.belnet.be, а от известно време на jabber.minus273.org, където nikky поддържа страхотно услугите) и то само когато наистина имах нужда от айсикю, тоест за връзка с тези няколко човека. И въпреки това е неудобно. А многопротоколен клиент не ща да ползвам — аз се радвам на напредъка на XMPP, чета доста за джабер-разработките и плановете за бъдещето, а и най-малкото това е протоколът за моментни съобщения, който е стандартизиран. Ако ползвам моментни съобщения днес, то е най-вече заради джабер. Затова ми допада как първо Google с техния GTalk/GMail (вредно недоразумение, между другото, но все едно;), после с налагането им на библиотеката Jingle, а сега и AOL с тази интеграция просто “влизат в правия път”. ;)

Новината е сериозна, но докато пиша това, клиентът ми още не се е свързал. Явно наистина сървърът xmpp.oscar.aol.com е претоварен от нетърпеливи ентусиасти в момента. Грешката е заради изтичане на време, не някаква друго и това ме кара да мисля, че натовареността е приемливо обяснение.

Накратко, за да се свържете с icq-сметката си през джабер, ползвайте JID от вида icqnumber [at] aol [dot] com към сървъра xmpp.oscar.aol.com със съответната парола на icq-сметката и на стандартния порт 5222. Трябва да се ползва TLS, но то повечето съвременни клиенти се свързват по подразбиране през TLS. Доколкото разбирам, би трябвало да работи и свързването с AIM — пак на същия сървър, но с JID aimusername [at] aol [dot] com. Няма да пробвам, макар да имам някакъв “вегетиращ” акаунт — поне от другите затворени протоколи успях да се отърва ;)

Ето го и схематично:

 
1. JID — icquin [at] aol [dot] com или aolusername [at] aol [dot] com
2. Host: xmpp.oscar.aol.com:5222
3. разрешаване на SASL PLAIN
4. включване на StartTLS
  

Аз още не съм се свързал, но то си е алфа-тестване и явно наистина е натоварено. А и честно казано, нямам никакво намерение да прехвърлям общуването си към айсикю, пък било то и през джабер-шлюз. Ако този вид свързване проработи, ще го ползвам в крайни случаи, при връзка с айсикю-списъка ми. Поне няма да го има разкачването на някои от транспортите… а, и също редовните проблеми с кодирането на кирилицата при писане с icq-номер.

Иначе засега мрежата на ICQ/AOL си остава затворена, защото обратната връзка май е невъзможна. Тоест не може някой с айсикю да ме добави мен с моето JabberID. GTalk/GMail се присъединиха към xmpp-федерацията и връзката е двупосочна, но дори и така да стане със сървърите на ICQ след време… пак бих имал резерви при общуването в прав текст нешифрирано с хора към такива централизирани сървъри. Сигурността при общуването през джабер винаги минава през една “тясна” част и това е паметта на сървъра. А “големите” в бранша имат навика да “помнят” всичко и такова намесване на “1984”-усещане е неприятна тръпка. Освен ако не се ползва шифриране от край до край, винаги текстът се дешифрира в сървъра. Тъй че макар и за момент, комуникацията може да е достъпна в явен вид за някой сдобил се с root-достъп до сървъра, дори и да минава през шифриране между сървърите и към клиентите през TLS. Да, вярно — това изобщо не е болка за умиране, особено за такива неща като чат и изобщо щом не става дума за парични преводи, а за дреболии като разговори, хич не е толкова важно. Вярно, някой може да кракне както голям, така и малък сървър, но лично аз имам повече спокойствие за поверителността на данните си, ако са по-далечко от “големите” сървъри.

И все пак всичко това е добра новина. XMPP е правилният начин, защото е описан подробно, публикуван е и е стандартизиран. Освен основната част на протокола има и огромен брой допълнения (“предложения за подобряване”, JEP). Които описват практически всичко, за което днес можем да си помислим в света на моментните съобщения. И с развитието на идеите се пишат нови JEP-ове и клиентите с отворен код ги имплементират бързо.

Тъй че добрата новина е за нас, ползващите джабер. За тези с icq сигурно няма да има разлика, а и едва ли ще има значение. ;)

Gaim е многопротоколен клиент за моментни съобщения. Първначално името е било “GTK+ AOL Instant Messenger” - всъщност корените на тази програма, която днес от доста хора се използва като jabber-клиент са оплетени с протокола за съобщения на “Америка онлайн”. Сега става ясно и защо Gaim винаги е бил неподходящият избор за джабер-клиент. Неподходящ избор и за програма за моментни съобщения изобщо.

Защо неподходящ? Ами винаги при Gaim е жертвана функционалност в името на поддръжка на повече протоколи. Вярно, доста време това беше удобна програма за icq - когато беше почти невъзможно човек да убеди приятел, че наистина не иска, не иска и не иска да ползва icq при наличието на свободната и по-развита алтернатива Jabber/XMPP. Дълго време точно разработчиците на Gaim първи правеха хаковете из icq-библиотеката си, за да е съвместима с поредната тайна и внезапна промяна в протокола на icq. Други екипи (например сещам се за този на Miranda) разчитаха да ползват поправения icq-плъгин точно от екипа на Gaim.

Gaim изпусна възможността да стане програмаТА за съобщения в GNU/Linux среда и се залиса по постоянно хакване на собственическите протоколи. В същото време джабер-сървърите вече поддържаха транспортери и всички разпространени собственически протоколи за моментни съобщения можеха да се “прекарват” през джабер-сървъри. Съответно на потребителя му трябва наистина добър - стандартен, поддържан и работещ джабер-клиент. А приставката на многопротоколния Gaim никога не достигна истинско уважение сред ползващите предимно и само jabber.

Проблемът с името е легален - AOL дълго време са водили тайни преговори с екипа на Gaim. Причината в началото е била в първото име на проекта, което съдържа запазена търговска марка на компанията. След това, при преименуването на Gaim проблемът е останал, понеже AOL като големи хитреци са регистрирали “AIM” за означаване на своя си клиент за моментни съобщения. “Gaim” прилича прекалено много на “AIM” и явно от гиганта са притискали дълго време разработчиците със заплахи за скъп процес. Накрая, по съвет на правните си консултанти, разработчиците решават да прекръстят проекта отново и да “избягат” от нападките на медийния гигант.

Новото име на програмата е “Pidgin”, библиотеката се преименува от “libgaim” на “libpurple”, а конзолният текстов клиент от “gaim-text” става “Finch”. Страхотна логика и говорящи имена, нали?… За всичко това е подписано и споразумение с AOL и спираното от правни спорове излизане на новата версия 2.0 на програмата вече е обявено. Само че под друго име - Pidgin.

Всъщност името “Pidgin” съдържа донякъде скрит смисъл - думата pidgin (пиджин) означава междуетнически контактен език. Това е такъв език, който се формира много бързо при нуждата говорещи на два или повече езика различни групи хора да общуват. Най-често - за търговия или при колонизиране. Намекът явно е за многопротоколността на програмата - Pidgin “говори” няколко езика, поддържа няколко затворени собственически протокола. Хитро.

Нямам големи симпатии към многопротоколните клиенти, а и Gaim от доста време вече не ми вършеше работа за инцидентно свързване при нужда с icq без шлюз на джабер. Явно два месеца да се изостави хакването на icq-протокола е достатъчно, за да спре да работи приставката.

Има развитие в разработката на Gossip и Gajim, очаква се и новата верися на Psi. Дано по-скоро екипите внедрят и поддръжка за пренос на глас и видео. Гугъл нали затова “натиснаха” общността за своята библиотека “jingle” преди време. А Gaim, Pidgin и подобните им - интересни са, да. Но определено пропиляха отдавна шанса си да са водещи в технологията за моментни съобщения.

Основно общуването ми в мрежата минава през Jabber, дори поща пиша все по-рядко и всеки път все по-трудно и със закъснения. Но все още ми се налага да се включвам към други мрежи, защото трима-четирима (от днес - с един по-малко) ползват нещо различно. Винаги първо предлагам джабер-името си за контакт, но какво да се прави… Покрай този ми “страничен” вече опит с другите протоколи се сблъсквам с най-различни и странни неща. Може би е странно и неудобно само за мен да не мога, например, да пиша на всички на кирилица (или с йероглифи, ако реша…), да не съм сигурен дали отсреща ще приемат или дали изобщо ще видят заявката ми за файлов трансфер, да не зная кой в момента ми е в списъка с контакти и дали изобщо съм свързан със сървъра… Може би съм леко “разглезен” от удобствата на Jabber/XMPP, но все пак всичко има своите граници.

Когато ми се наложи, ползвам транспорти към другите протоколи през мой или публичен сървър. Но понякога ми се налага да пускам многопротоколен клиент с вградена поддръжка на icq. За да съм поне малко по-сигурен в комуникацията с приятелите ми в icq. Тези дни ползвам Kopete.

Тия от icq ме разбиват, без майтап - днес гледах невярващ как получавам следното съобщение “$nickname is now online (Invisible)”. Това се получи не веднъж, получава се цял ден при смяна на състоянието на контактите, които явно искат да са “невидими”. Явно им се “препокриват” автоматичното състояние “отсъстващ” (“away”) и ”невидим”.

Мислех, че състоянието “невидим” в icq от доста време вече е внедрено правилно и когато човек е “невидим”, другите хора просто не го виждат. Но не - оказва се, че редовно в icq-бърлогата се размятат такива съобщения. Просто оригиналният icq-клиент ги пренебрегва. Получава се следната схема, която ако не беше отчайващо тъпа, щеше да е само смешна.

Клиент1 избира да мине в състояние “невидим” и изпраща съобщение на сървъра от сорта на “хей, пич, аз съм невидим, чуваш ли?”. Сървърът сигурно (би трябвало, но никой не знае, протоколът е собственически) му изпраща някакво потвърждение “добре бе, стига си ме занимавал, невидим си!”. И когато някой от другите клиенти, например Клиент2, обнови списъка си и запита за Клиент1, сървърът му отговаря “тоя не го закачайте, невидим бил”. Клиент2 пропуска това съобщение покрай ушите си и за човека пред програмата на Клиент2 наистина Клиент1 не е от нещата, които вижда.

И все пак… ако си заровиш главата в пясъка, това не значи, че светът е станал невидим. А само, че ти отказваш да го гледаш. Във времето на все по-голяма свързаност и споделяне да се изхожда винаги от такава свръх-субективна позиция е глупаво. Просто не работи.

Мисля, че дори няма да ми е интересно кога icq ще поправят това. Има по-интересни неща - например развитието на джабер.

Да, става дума за сигурност. Преди да продължа и да кажа, че общуването през Jabber/XMPP може да бъде несигурно, нека ви напомня нещо.

Именно, че общуването през всичките нароили се други протоколи *не е сигурно*. Когато някой от вас ми казва “ами хайде, сложи си “Q” или “Яху”, щото нали най-важното за месинджърите е колко хора ги ползват, кво се правиш” все се сещам за онези времена, когато се използваха наистина масово т.нар. “icq клиенти”. На половин година излизаше нова версия, но пък за сметка на това всеки месец излизаше по някоя нова програмка-“инструмент”. Я за подслушване, я за заливане до отказ на клиента, я за крадене на списъка с контакти…

Любимият ми пример всъщност е този с “невидимостта” в icq. Не зная как се осъществява състоянието “невидим” в днешните собственически програми за моментни съобщения и не ме интересува, честно казано. Но навремето сътсоянието “невидим” (“invisible”) в небезизвестното icq беше направено по супер-балъшки начин.

Значи минавате вие в “невидимост” и какво става? Ами много просто - icq-то ви казва на всички, че сте невидим. Невидимо е не *то*, а… *вие*. Получава то запитвания за състояние и на всяко запитване отговаря, че състоянието ви е “невидим”. Нещо като “Мен ли търсите? О, мен ме няма, не мога да говоря по телефона, защото ме няма. Приятен ден!”. После е ясно откъде се появяваха т.нар. “un-invisiblisers”.

Тоест всичко е измисляно “през пръсти”. Пък ако мине номерът - мине…

Правилният начин, както може би сте се досетили, е в състояние “невидим” на запитвания за състояние да не се отговаря. Така де - когато “няма никого вкъщи” не отваряте вратата, нали? ;)

Jabber също не отваря вратата, ако още се чудите. ;)

——

Но въпросът е за сигурността. Най-важното за сигурността е, че трябва да бъде осигурявана.

Глупаво е да се мисли, че има универсални решения. Всъщност аз бих могъл да ви кажа, че е глупаво да се мисли, че изобщо има решения. Повлиявам се от философския си background, ще кажете вие. Добре, тогава бих добавил, че е човешко да бъдем глупави.

Но все пак в среда, в която можем да бъдем “моделирани”, среда, в която определяща е само информацията и не толкова това, което ни я дава, в среда, в която всяко “сигурно” нещо може да бъде фалшифицирано и то по “сигурен” начин, в такава среда просто трябва да бъде естествена реакция грижата ни за сигурността.

Трябва да имаме security reflex. ;)

Защото колкото и закони да пише държавата, в Интернет едно е ясно - винаги невинният може да бъде набеден по достатъчно убедителен начин. И виновният може да не остави достатъчно убедителни следи. Въпрос на гледна точка.

Освен ако не държим на сигурността и не използваме в общуването достатъчно сигурни (поне към днешни дни) механизми за шифриране да информацията.

——

След като ви казах, че използвайки собственическите програми за моментни съобщения вие почти сигурно говорите “голи”, да кажа и за Jabber.

Jabber поддържа няколко нива на защита на преминаващите данни.

1) шифрирана връзка към сървъра (c2s, client to server) през SSL (Secure Socket Layer) на друг порт, 5223

2) шифрирана връзка към сървъра (c2s) през TLS (Transport Layer Security) на стандартния порт за нешифрирана връзка, 5222

3) шифрирана връзка между сървърите (s2s, server to server) през SSL

3a) други варианти на подобна схема на s2s шифриране.

4) шифрирана връзка на цялата комуникация между двата клиента (e2e encryption, end to end encryption) чрез подписване и шифриране на данните с електронни ключове.

Въпросите тук са два:

1) кой вариант или кои комбинации са достатъчно сигурни и

2) кое доколко е въведено в наличните днес сървъри, сървърни компоненти и клиенти.

Първият въпрос е лесен за отговаряне.

Най-сигурният вариант е 4). Когато всичко е шифрирано от единия край до другия, данните са най-добре защитени.

След него се нарежда вариант 3) в разновидностите му, комбиниран с 1) или 2). Тогава данните изминават следния път: първо клиент1 ги шифрира до сървър1, след това сървър1 ги шифрира за вътрешния обмен между процесите си и/или до сървър2 (ако разговорът е между хора към различни сървъри) и накрая сървър2 ги шифрира до клиент2.

За да работи тази схема са нужни две условия - и двата клиента да са свързани през SSL или TLS към сървъра си и всеки от включените в разговора сървъри да е настроен да шифрира данните.

Въпреки че тази схема е доволно добре изглеждаща, има слаби точки. Тези точки са двата сървъра, или по-точно администраторите на двата сървъра. Съответно - сигурността на двата сървъра, защото ако са несигурни и незащитени, има възможност някой си друг да стане практически “администратор” и… сещате се;) Обяснението е, че всяко нещо, което минава нешифрирано през машината и зависи от програмно осигурената услуга да бъде шифрирано, е уязвимо. Да обясня с пример: ако кракер1 добие достъп до, да речем, сървър2, то той може така да промени софтуера на машината, че, примерно, да изпраща нешифрирано копие на данните до кракер-клиент1. Или още по-“яко” - да изпраща шифрирано от кракер1 копие.

А най-опасното е да имате или връзка със сървъра през SSL, или връзка между сървърите през SSL, но не и двете едновременно. Най-лошо е, защото си мислите, че сте защитени (понеже, примерно, “катинарчето” на клиента ви е заключено), но не сте (в случая - защото между сървърите всичко е в прав текст).

——

Да видим каква е реалността. Доколко тези възможности са внедрени в сървърите, компонентите, клиентите.

От компонентите ни интересуват най-вече транспортерите към другите протоколи. При тях положението е ясно - няма защита. Защо ли? Ами много просто - доколкото поне на мен ми е известно, защита нямате и в самите въпросни собственически протоколи, как Jabber сървърът да я “измисли” тази защита? ;)

При клиентите също нещата са ясни - все пак клиентите ги “виждаме”, пред нас са. Списъкът им се променя много често, все по-често излизат и нови версии. И все пак единственият клиент, който хем е колкото може по-съвместим с протокола, хем поддържа SSL, TLS и e2e шифриране, е Psi. С Psi направо можете да си настроите електронните ключове - вашия и този на събеседника ви и след като минете в засекретен режим, да говорите спокойно. Без това да бъде “нещо специално”. Както казах, просто рефлекс за сигурност. ;)

В другите клиенти положението не е чак толкова добро, но има проблясъци - Gaim, колкото и оплюван от Jabber-общността, поддържа шифриране и всичко останало, макар и през допълнителни приставки.

В някои други клиенти има наченки в новите версии на e2e crypt - Kf, Gajim.

В някои клиенти пък изобщо липсва такава възможност. Много са, но ще спомена само един от най-качествените сред тях - Gossip, бъдещият стандартен Jabber-клиент за настолната среда Gnome. Колкото и да е странно, в пощенския списък на Gossip като че ли битува едно разбиране, според което ако хората използват SSL връзка със сървъра, всичко е наред - и “пей, сърце”. Дано в дълго готвената нова версия включат и шифриране между клиенти. Макар силно да се съмнявам - просто понякога се прекалява с “user friendly” обяснението. Gossip малко прекаляват с прекалената изчистеност. Аз използвам Psi в среда на Gnome и съм доволен от интеграцията му. Пък и ако “съвместимост със средата” означава да нямам сигурност на данните защото “било трудно за новия потребител”, ами… майната й на съвместимостта…

При сървърите положението едва напоследък започна да става по-розовичко. Доскоро, именно до 20.01.2005г., когато излезе версия 1.4.4, един от най-разпространените (и всъщност първият, оригиналният;) сървъри, jabberd14, *НЕ* поддържаше SSL връзка в междусървърната комункация.

Новата версия, 1.4.4 поддържа.

Другият разпространен сървър, jabberd2 също доскоро не поддържаше шифриране. Ето едно примерно доказателство.

Последните версии поддържат. Проблемите с внедряването на s2s SSL бяха най-вече свързани с трудността при критериите за автоматичното приемане на сертификатите - някои сървъри може да имат изтекли, самоподписани сертификати и т.н. А администраторът да решава “на ръка” за всеки сървър и да следи дали сертификатът е валиден… си е гърч ;)

Третият най-използван сървър, руският написан на Erlang ejabberd и в момента *НЕ* поддържа s2s шифриране. В сайта му вижте най-долу. За всеки случай ще цитирам:

Misfeatures of ejabberd

No support for authentification and STARTTLS in S2S connections

Трябва да се отбележи, че фактът, че някои от сървърите отскоро вече имат възможност за s2s шифриране *НЕ* означава, че на практика тази възможност е настроена в самите сървъри. Или че изобщо сървърните пакети са обновени. Затова - проверявайте. Добрият клиент трябва да поддържа ServiceDiscovery (“disco”) и да може да дава подробна информация за сървъра.

——

И сега - какво? Ами… нищо - аз си ползвам шифриране с електронни ключове в моя Psi. И говоря свободно само с малкото хора в списъка ми, които са включили тази настройка, защото разбират положението на нещата.

Говоря и с другите; някои от тях са ми близки приятели. Но внимавам какво пиша и давам чувствителни данни само ако те се съгласят и след като им кажа, че връзката не е сигурна. И го правя с нежелание.

Но какво да се прави. Всъщност то все още има линуксчии, всякакви други хора, вярващи в софтуерната свобода, които продължават да използват icq, yim, msn и какви ли още не бозици.

А пък аз съм тръгнал да говоря за сигурност…

В обобщение: използвайте колкото се може по-близък сървър. Не само заради скоростта на връзката до него, а и заради по-голямата възможност да познавате администратора му и/или да имате по-голямо доверие на специалистите и защитните стени около машинката. ;) Проверявайте версиите и другите данни за сървъра - от уеб-страница за състоянието му или през disco.

И второ - използвайте винаги SSL/TLS връзка със сървъра. Не вреди, а пък в редки случаи може да повиши сигурността на връзката. Е, поне паролата ви към сървъра е защитена. ;)

И накрая, но най-важно - използвайте GPG за шифриране клиент-клиент. Намерете си клиент, който го поддържа и разкажете на хората в списъка ви за предимствата.

За да може някой ден да приемаме сигурността като нещо естествено, а не нещо супер-специално и прекалено user-unfriendly. Да си изградим security reflex. ;)