Portál AbcLinuxu, 19. dubna 2024 20:49
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...)
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ě...
17.12.2007 16:37
David Heidelberg | skóre: 46
| blog: blog_
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..
17.12.2007 16:51
kouzer | skóre: 11
| Mladá Boleslav
Když už jsem Qt 4 musel zkompilovat kvůli Psi, rád vyzkouším i tohle. Proč ne, třeba to bude použitelné.
17.12.2007 17:07
kouzer | skóre: 11
| Mladá Boleslav
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í. 
17.12.2007 19:00
kouzer | skóre: 11
| Mladá Boleslav
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.
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.
17.12.2007 23:05
<!-- 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/>
Jasně, o tom nepochybuju. Šlo ale hlavně o tu klasickou otázku, zda se plaintextem posílá heslo.
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.
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ě.
Š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.
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 budeNavic 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.
19.12.2007 18:33
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.
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.
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ě.)
18.12.2007 12:44
kotyz | skóre: 25
| blog: kotyzblog
| Radnice
Je toho hodne k vyzkouseni ...
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
