Да, става дума за сигурност. Преди да продължа и да кажа, че общуването през 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. ;)
