Experimenty s Jabberem (diskuse)

[ajikdpoe]

suhlasim, chcem(e) prenos audia, videa, plne funkcne zdielanie suborov, scratchpad, ... pokial mozno ihned

[Spike]

Používej Windows Live Messenger a máš to hned, když jsi tak nedočkavý.

[Andrej]

Jooo? No ale nechceš toho trochu moc? To, co popisuješ, uměl Microsoft NetMeeting, když jsem ho kdysi používal, ale to je closed-source, že jo...

Je několik jabberových serverů, které něco podobného umí, ale má to hned dva háčky. Zaprvé, který klient to podporuje? Zadruhé, něco velkého podruhé instalovat by mě zabilo. (Grrr...)

[Andrej]

Pokud narážíš na fakt, že Skype tohle všechno má, máš sice pravdu, ale ani to jeho oblibu u mě příliš nezvyšuje. Mnohem raději použiji Ekigu s otevřeným protokolem (když chci videokonferenci) nebo SIP (Twinkle) (když chci telefonovat, včetně příchozího čísla a běžných telefonních sítí). Kromě toho, pokud vím, zatímco GnomeMeeting (Ekiga) podporuje videokonference odjakživa, Skype (beta!) s touto vymožeností pro Linux přišel teprve nedávno. U Skype mi (kromě jiného) chybí například možnost vybrat si kodek. Často je vybrán nevhodně a kvalita je bídná.

ICQ raději nechávám stranou. Podle mého názoru je to buggy šmejd, který prý má všechno možné, ale nic z toho ve skutečnosti nefunguje.

Pokud jde čistě o instant messaging, vůbec bych to s tím Jabberem neviděl tak černě...

[David Heidelberg]

Tak ono u toho Psi asi zůstaneš. Ohledně podpory jabberu je na tom nejlíp. Na linuxu používám kopete 0.40 z svnka(ohledně stability hrůza, ale co nadělám) a pod windows nightlies Psi 0.11 a ten funguje super.

[Andrej]

Takže situace je asi opravdu taková, jak jsem se obával. Kdekdo Jabber vychvaluje, ale otázka je, k čemu jsou servery bez klientů. Existuje víc než 6 (více či méně kompletních) implementací serveru, zatímco použitelných klientů je jako šafránu..

[Josef Kufner]

Psi e sice celkem spolehlivé, ale umí jen nutné minimum.

[kouzer]

Bude to trochu mimo mísu, ale já si hraju s tímto. Je to v ranném stádiu, ale já jim fandím.

[Andrej]

Když už jsem Qt 4 musel zkompilovat kvůli Psi, rád vyzkouším i tohle. Proč ne, třeba to bude použitelné.

[kouzer]

U mě běhá naprosto bez problémů. Stačí postupovat podle návodu na webu. Jednou za prá dní dělám svnu up a nemám žádný problém. A když se nudím, tak studuju zdrojáky.

[Andrej]

Tak to já teď zrovna kompiluju PyQt 4 a k tomu navíc ještě „legacy“ PyQt 3, aby to všechno mohlo v mém počítači spolubydlet. To jsem zvědavý, či to bude stát za to úsilí.

[kouzer]

Pokud umíš python, tak určitě se vynalézavosti meze nekladou...

[Andrej]

Python sice neumím, ale tento projekt je sám o sobě vynalézavý až dost. Líbí se mi, že to má hodně rychlou odezvu. Fungovalo to na první pokus, i s podporou starttls. Každopádně díky za dobrý tip. Už jsem Jabbim přidal do seznamu vyhovujících klientů v mém blogu.

[CET]

Muzes mi letmo naznacit nejaky citelny rozdil mezi SSL a starttls? Mel jsem za to, ze v tom rozdil neni (resp. SSLv3 a TLSv1), pouze je rozdil v pouziti - zatimco SSL je sifrovane od zacatku spojeni, TLS se startuje v plain-text komunikaci po navazani spojeni. Mozna se pletu, ale zdalo se mi, ze sifrovani je stejne. Cili vyhoda plyne akorat z pouziti: sifrovani se muze a nemusi startovat na jednom portu, server muze pouzivat jedno IPcko pro vice certifikatu, pokud protokol podporuje urceni virtualniho hosta. Vic me nenapada.

[pinkolin]

Hlavni vyhoda jsou ty certifikaty...

[Andrej]

No právě kvůli nim jsem chtěl starttls. V plain textu se zaručeně neposílá nic. Stačí jen zakázat jakýkoliv nešifrovaný přístup a hotovo.

<!-- Require STARTTLS. If this is enabled, clients must do STARTTLS
     before they can authenticate. Until the stream is encrypted,
     all packets will be dropped. -->
<require-starttls/>

[Spike]

V plain-textu se zaručeně posílá prvních pár packetů komunikace mezi serverem a klientem, než se restartne stream a začne se šifrovat pomocí TLS.

[Andrej]

Jasně, o tom nepochybuju. Šlo ale hlavně o tu klasickou otázku, zda se plaintextem posílá heslo.

[Spike]

No, i kdybys nepoužil TLS, tak standardně se většina klientů pokusí pro autentizaci použít hash hesla, pokud to server nabízí (Google Talk třeba ne, proto má taky starttls required).

[pinkolin]

tak toho minus je zase nesifrovane heslo v databazi. (ted jsem asi spustil flame)

[Andrej]

Proč flame? Vždyť je to pravda. Ano, heslo je v databázi uloženo nešifrovaně a existuje spousta (více či méně legálních) možností, jak ho odtamtud získat.

Výhodu zase vidím v tom, že se nedá odchytit ani login. Ten sice není určen k utajení, ale neznalost loginů velmi ztěžuje možnost slovníkového útoku.

[pavlix]

DIGEST by měl jít používat tak, aby nešifrované heslo nebylo ani v databázi, ani přenášené po síti.

[CET]

Tak koukam, ze toho mozna vim o trosku vic nez vy. SSL taky pouziva certifikaty, muze bud jenom klient overovat certifikat serveru, nebo i server muze overovat klintskej certifikat.

SSL hned od zacatku komunikuje sifrovane, tedy samozrejme v plainu si posle uvodni inicializaci klicu a dal masti sifrovane.

TLS bezi uvnitr plain-text komunikace, cili zacne se plain-text a pak klient vysle (nebo nemusi) prave ten "starttls" a tim se inicializuje sifrovana komunikace. Zadnej rozdil oproti SSL co se tyce sifrovani nevidim. Obe dve se sifruji stejne (pokud jsem dobre videl, sifrovaci algoritmy jsou stejne pro SSLv3 a TLSv1). Navic v SSL se k tobe nepripoji ne-SSL klient, cili se nemuze stat ani nahodou, ze by klient omylem poslal auth udaje nesifrovany a server mu pak odpovedel, ze musi prihlasovaci udaje sifrovat (napr. IMAPem poslu login user password a uz je pozde na vynuceni sifrovani) - z toho duvodu mam radsi SSL.

Jinak SSL se mi zda taky lepsi na debugovani, protoze openssl s_client funguje skvele pro vsechny protokoly, kdezto TLS podporu ma openssl s_client zatim pouze pro smtp, imap a pop3 (coz teda nastesti asi bude stacit vsem, ale osobne testuju pouze SSL nebo plain-text).

[Andrej]

Já se nepřu o výhodách/nevýhodách té které technologie. Například jabberd2 může bez problému využít tentýž certifikát pro SSL i TLS. Faktem ovšem je, že SSL spojení začíná být postupem času „deprecated“ a je vytlačováno TLS. (To samozřejmě platí výhradně pro Jabber, nikoliv pro ostatní internetové technologie.) Tento trend je vidět například v dokumentaci k serveru jabberd2 nebo ke klientům Gajim, Pidgin, Jabbim a Psi. Spojení přes SSL tam bývá často nazýváno legacy a podobně.

To je hlavní důvod, proč jsem přednostně zprovoznil pouze TLS. Dalším důvodem je fakt, že bez SSL má člověk v iptables o jeden povolený port méně.

[petr_p]

Zavržení SSL je zrovna tak patrné i u SMTP. Sehnat server s nativní podporu SMTPS i na straně SMTP klienta (zdravím český telecom) je dnes prakticky nemožné.

[CET]

No, slusna firma, pokud dela mail hosting pro zakazniky s auth, tak by to podporovat mohla. Na druhou stranu, proc by se tim nekdo zabyval, kdyz snad kazdy provider nabizi svym zakaznikum odesilani emailu ze svoji site bez autentizace. SSL/TLS by pak akorat zatezovalo smtp server a slouzilo by pouze jako skryvac textu mezi klientem a smtp serverem a dale by byl email nesifrovany.

[petr_p]

Telecom není „každý provider“. Jeho SMTP relay vyžaduje PLAIN autentizaci. A v případě, že nemáte celý drát od vašeho serveru do Telecomu pod dohledem, tak se šifrování jeví jako rozumná volba.

[pinkolin]

Hlavne jde o to, ze certifikat pro SSL je vazan na IP. Pro technologii, ktera ma podporu vhostu v sobe je to trochu na nic. Zvlast pri nedostatku IP.

[Spike]

Šifrování na samostatném portu není popsáno/standardizováno jako součást XMPP, na úkor starttls. Proto je „deprecated“.

[CET]

Šifrování na samostatném portu není popsáno/standardizováno jako součást XMPP, na úkor starttls. Proto je „deprecated“.

No, tak to jsem nevedel, takze samozrejme v tom pripade akceptuju vyber TLS.

[Spike]

Navic v SSL se k tobe nepripoji ne-SSL klient, cili se nemuze stat ani nahodou, ze by klient omylem poslal auth udaje nesifrovany a server mu pak odpovedel, ze musi prihlasovaci udaje sifrovat (napr. IMAPem poslu login user password a uz je pozde na vynuceni sifrovani) - z toho duvodu mam radsi SSL.

To ho máš radši z naprosto hloupého pseudodůvodu, protože se starttls samozřejmě můžeš dosáhnout toho samého. Například v Psi 0.11 lze nastavit, aby vyžadovalo šifrování (i na standardním portu). Je to jen blbost klienta, pokud neumí vyžadovat šifrování, nikoli chyba návrhu starttls.

[CET]

Navic v SSL se k tobe nepripoji ne-SSL klient, cili se nemuze stat ani nahodou, ze by klient omylem poslal auth udaje nesifrovany a server mu pak odpovedel, ze musi prihlasovaci udaje sifrovat (napr. IMAPem poslu login user password a uz je pozde na vynuceni sifrovani) - z toho duvodu mam radsi SSL.

To ho máš radši z naprosto hloupého pseudodůvodu, protože se starttls samozřejmě můžeš dosáhnout toho samého. Například v Psi 0.11 lze nastavit, aby vyžadovalo šifrování (i na standardním portu). Je to jen blbost klienta, pokud neumí vyžadovat šifrování, nikoli chyba návrhu starttls.

Eee, rekl bych, ze jsi me spatne pochopil - jde mi o to, ze kdyz bude spatne nastavenej klient, tak muze poslat auth udaje nesifrovany, pokud server bude podporovat TLS v ramci plain-text spojeni (ted fakt netusim, jestli muze starttls vynutit i server, takze o tom se prit nebudu a klidne to akceptuju, pokud nekdo rekne, ze to server umoznuje). Uvedu na prikladu:

Klient je spatne nakonfigurovanej a nespusti starttls. Klient, napr. IMAP jak jsem psal, se pripoji k serveru a posle logovaci udaje, napr. hned prvni prikaz bude a0 login USER PASSWORD. Server na to muze klidne odpoved neco ve smyslu, ze pro prihlaseni pozaduje TLS, ale bohuzel - heslo uz slo siti nesifrovany. V pripade POP3 nebo SMTP a mozna i dalsich se nejdrive posle USERNAME a server muze reagovat zamitave.

Pokud se ale klient pripoji pres SSL (a pripojeni pres plain-text zakazu), mam zajisteny, ze logovani pujde ihned pres sifrovanej kanal.

To jsem mel na mysli, ale jak jsem uz psal, tohle plati pro IMAP a nevim pro ktere dalsi protokoly. Jinak samozrejme kazdej normalni klient provede nejaky otestovani prikazu, pripadne se dotaze, jestli muze autentizovat a server muze odpovedet, ze bez sifrovani ne. Napr. ldapsearch pri pripojeni s autentizaci na port 389 (nesifrovany a bez TLS) od serveru (pokud je tak nastavenej) obdrzi hlasku "confidentality required", ale netusim, jestli to dostane jako odpoved na pozadavek autentizace nebo az po zaslani hesla.

[Spike]

„Špatně nastavený“ klient je pak i ten, který není nastavený na port 5223. Když už si ho uživatel může nastavit na port 5223, tak si ho může nastavit i na „šifrování vždy“. Pořád nevidím žádnou výhodu.

[pavlix]

Tohle by se tuším nemělo u jabberu projevit, ten problém, co popisuješ na IMAPu.

[CET]

Je to jen blbost klienta, pokud neumí vyžadovat šifrování, nikoli chyba návrhu starttls.

A jeste jsem zapomnel dodat. To mas sice pravdu, ale pak je muj problem, kdyz se mi nekdo dostane na server, protoze si nekdo spatne nastavil klienta, kterej posla ID udaje plain-textem a nejakej zaskodnik to odchytnul a zneuzil.

[Spike]

Dostane se ti na server? To by mělo mrzet hlavně uživatele. A pokud ten zcizený účet začne používat pro nějaké nekalé účely, můžeš ho zablokovat. Jinak nechápu, co myslíš tím „dostane se ti na server“.

Můžeš klidně dát starttls required (pak se ale nepřipojíš jen tak třeba z Bombuse a budeš potřebovat stejně SSL na samostatném portu; otázkou je, zda SSL pojede, pokud v telefonu už nemáš odpovídající certifikát od CA), nebo alespoň bez starttls nenabízet sasl-plain, ale pouze digest-md5 autentizaci.

[pavlix]

Koukám, že toho víš opravdu hodně....

Ale moc informací jsi teda nedal.

starttls lze taky vyžadovat (takže nehrozí nešifrované spojení).

Navíc starttls je systematičtější.... přidává šifrování do protokolu... zatímco klasický TLS/SSL od začátku vytváří jakoby druhý protokol.

To se odrazí na číslech portů a dělá bordel třeba v DNS.

Například, pokud mám pro doménu jeden jabber server (s2s i c2s), tak dám SRV záznam pro c2s a SRV záznam pro s2s a hotovo. Kdybych požadoval šifrování "od začátku", musím vydělovat speciální porty... a na ně odkazovat dalšími záznamy.

Debugování... ale nakonec... šifrovaný tunely můžeš stavět stejně... a nikdo ti v tom nezabrání (uvnitř služba poběží nešifrovaně a hotovo). Zase degradovat elegantní návrh kvůli o maličko snazšímu debugu by se mi nechtělo.

[Josef Kufner]

Navíc starttls je systematičtější.... přidává šifrování do protokolu... zatímco klasický TLS/SSL od začátku vytváří jakoby druhý protokol.

Zas tak černobíle bych to neviděl. Je to jen o tom, kde to bude složitější. Pokud použiju SSL, bude v komunikaci o vrstvu více. Pokud TLS, bude jedna vrstva složitější. Takže je to jen o tom, co se u toho či onoho vyplatí. Já upřednostňuju SSL – prostě mám radši víc jednodušších věcí. A co se DNS týče... kdo říká, že nešifrovaná varianta musí být k disposici? (Pokud to není kvůli kompatibilitě.)

[Josef Kufner]

Zkus tkabber.

[kotyz]

Ten Tkabber umi i hry a whiteboard. Ale i ten na druhy strane musi mit Tkabber. Jabbin a Coccinella zase umi hlasovy prenosy ale plati to samy, ten na druhy strane musi mit stejnyho klianta. Pak je tu Psi a Gajim, ktery toho zase tolik moc neumi. A nakonec Jabbim, kterej ma velky ambice do budoucna (ted sou tam zakladni funkce a par specialit a do budoucna muzou bejt hry, hlas i video).

Je toho hodne k vyzkouseni ...

[Josef Kufner]

Nesou to jen hry a whiteboard. Vlastně tyhle dvě věci jsem nikdy nepoužil. Ale umí třeba stromovitý roster, custom presence, vytváření skupin v rosteru podle regexpu, bookmarky v chatu, hledat v JUD, umí slušně MUC, má archiv zpráv (ještě vedle historie chatu), groupchaty má v rosteru a jako bonus je všecko hezky pohromadě v jednom okně.

[Spike]

Co jsem se ptal, tak poslední verze Empathy (s posledními verzemi telepathy-gabble a loudmouth) podporuje starttls.

Samozřejmě také umí audio a video přenosy. :)

Škoda, že takové projekty nejsou třeba pro KDE. Pro to je jen (docela slabé) Kopete a žádná konkurence.