Tag: jabber/xmpp

nach einer frischen linux mint installation habe ich den psi+ nicht zum laufen bekommen. bei der auswahl, dass immer ssl verwednet werden soll, wurde gemeckert, dass ein plugin fehlt. nach langer recherche hab ichs auch gefunden… naemlich das: libqca2-plugins-ossl
einfach ueber den package manager nachinstallieren und gut

ich nutze gerne jabber bzw. heute auch lieber xmpp genannt. auch wenn die “userbase” nicht sooo gross ist wie bei den platzhirschen im messaging. aber mittlerweile gibt es sogar brauchbare mobile apps dafuer.
seit 10,5 jahren betreibe ich auch einen (naja mindestens zwei) jabber server. anfangs noch mit openfire betrieben und offene registrierungen erlaubt, habe sich auch einige “fremnde” leute da registriert, die den dienst heute noch regelmaessig nutzen. die freien registrierung habe ich spaeter aufgrund von missbrauch fuer spam und tausenden “einmalkonten” geschlossen. ihr glaubt ja nicht, was so alles passieren kann, wenn man nachts schlaeft. aus zeitmangel habe ich aber nie eine freie registrierung mit opt-in oder sowas gemacht.
irgendwann gab es dann probleme mit zertifikaten und java und der openfire server musste prosody weichen. ich bin heute noch stolz, dass ich auch eine usermigration ohne grossen ausfall hinbekommen habe.

alle monde kam mal eine nachricht mit spam ueber den kanal.. das konnte man einfach ignorieren und loeschen. aber seit ein paar wochen aergern mich die spammer massiv mit nachrichten auf russisch – die ich halt nicht mal lesen kann. also die “noch-sinnloserer-spam-variante”. meine jid ist halt auch im netz verbreitet… aber einfach ne andere nehmen will ich auch nicht. um der sache herr zu werden, gibt es immer mindestens zwei varianten… whitelists und blacklists.

die whitelist waere die einfachste methode, ist aber auch nicht zielfuehrend, wenn mir nur noch leute schreiben koennen, die auf meinem roster (kontaktliste) sind. aussderdem wuerde das auch alle anderen nutzer des jabber servers betreffen.

also muss ne blacklist her. die sache mit den blacklists ist halt auch nicht das gelbe vom ei, da man die liste pflegen muss und mindestens einmal genervt wird. je nach verwendetem client sind es 3 bis 6 klicks, bis ein user auf der blacklist ist. nun gut – aber ausprobieren werde ich es mal. immerhin war es bis jetzt so, dass die spammenden adressen meist zweimal oder oefters ihren muell geschickt haben.

gesagt, getan … die entsprechenden module fuer das “blocking command” (XEP-0191) waren schnell gefunden. damits nicht ganz so einfach ist, werden verschiedene module in den prosody versionen 0.9.x und 0.10.x verwendet. nach den ersten tests ist es schon etwas ruhiger geworden. gluecklicherweise koennen meine verwendeten clients auch schon mit XEP-0191 umgehen.

und natuerlich musste ich mir auch anschauen, wie die sache umgesetzt ist… und da prosody eine sehr einfache datenbankstruktur verwendet, wundert mich auch nicht, dass die blocklist dann in so einer form abgelegt ist:

ok… wir schreiben mal alles in ein feld in der datenbank. (hier zu sehen sind “nur” drei jids). obwohl das feld in mysql als datentyp TEXT deklariert ist, duerfte da irgendwann feierabend sein. von performance und verarbeitungsweise mal ganz zu schweigen. aber auf meinem kleinen serverchen ist das vollkommen verschmerzbar.

bleibt nur zu hoffen, dass die sache mit dem spam managebar bleibt. aber ich sehe es schon kommen, dass auch bei jabber irgendwann leider so sachen wie spammassassin eingesetzt werden muessen. 🙁

ohne gross darauf einzugehen warum, weshalb… einfach als gedaechtnisstuerze fuer mich.

wenn man unter debian wheezy diese beiden pakete installiert hat:

openjdk-6-jdk
openjdk-7-jre

…dann ist standardmaessig java 6 die default version. ich weiss nicht, wie man das normalerweise und richtig macht. hier musste es schnell gehen und mir ist nur eingefallen:

update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-7-openjdk-amd64/bin/java 1100

und so siehts dann aus, wenn man “update-alternatives –config java” aufruft:

weiter gehts mit den ciphers, die java standardmaessig zur verfuegung stellt. manche sachen wie z.b. SSLv2, SSLv3, RC4 und irgendwelche “weak ciphers” will man ja nicht haben. um das abzustellen, fuegt man diese zeile (eine zeile!) in die datei /etc/java-7-openjdk/security/java.security ein bzw editiert diese, sofern schon vorhanden:

jdk.tls.disabledAlgorithms=SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DH_DSS_WITH_DES_CBC_SHA, SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DH_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA, SSL_FORTEZZA_DMS_WITH_NULL_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_IDEA_CBC_SHA, SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, TLS_DHE_PSK_WITH_RC4_128_SHA, TLS_ECDH_anon_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_PSK_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_RC4_128_SHA, TLS_PSK_WITH_RC4_128_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, TLS_RSA_PSK_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

und da man auch keine schluessel kleiner 1024 akzeptieren will, auch noch diese zeile:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

openjdk hats irgendwie auch nicht so mit der validierung von remote zertifikaten, weshalb das mit dem TLS dialback nicht funktioniert. deshalb muss man in der datei /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/java.security auch noch diese zeile auskommentieren: (mit einem # anfang versehen)

security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

und dann noch die sache mit dem importieren eines von einer CA signierten zertifikates… dazu brauchts:

– das zertifikat selbst (jabber-signed.pem)
– den key (jabber-private.pem)
– die “certificate chain” der CA auch im PEM format (hier chain1.pem und chain2.pem)
– ImportKey.java von agentbob

los gehts…

in der datei “ImportKey.java” von agentbob diese zeilen den eigenen gegebenheiten anpassen:

[..]
String keypass = "changeit";
[..]
String defaultalias = "private-key";
[..]
String keystorename = "keystore";

und dann die ImportKey.java mit diesem befehl kompilieren:

javac ImportKey.java

und so fortfahren:

/etc/init.d/openfire stop
cd /etc/openfire/security
cp truststore truststore.org
cp keystore keystore.org
keytool -importcert -alias chain1 -keystore truststore -file chain1.pem
keytool -importcert -alias chain2 -keystore truststore -file chain2.pem
openssl pkcs8 -topk8 -nocrypt -in jabber-private.pem -inform PEM -out jabber-private.der -outform DER
openssl x509 -in jabber-signed.pem -inform PEM -out jabber-signed.der -outform DER
java ImportKey jabber-private.der jabber-signed.der
/etc/init.d/openfire start

in der admin webgui steht bei dem key nun “pending verification”… stimmt garnicht. hab ich einfach ignoriert. genauso wird angezeigt.. “One or more certificates are missing. Click here to generate self-signed certificates” ..stimmt auch nicht. hab ich auch einfach ignoriert.

ich denke, das wars. mit dem “IM Observatory” auf xmpp.net kann man anschliessend testen, ob nun alles so ist, wie man sich das erhofft… voila:

notiz an mich selbst…

srv dns records (bind) fuer jabber (xmpp) haben ungefaehr so auszusehen:

_xmpp-server._tcp 3600 IN SRV 10 0 5269 ejabberd.example.net.
_xmpp-client._tcp 3600 IN SRV 10 0 5222 ejabberd.example.net.  

und wenns funktioniert, sieht das ergebnis so aus:

$ dig _xmpp-client._tcp.example.net SRV +short
10 0 5222 ejabberd.example.net.
$ dig _xmpp-server._tcp.example.net SRV +short
10 0 5269 ejabberd.example.net.

und der vollstaendigkeit halber.. so gehts mit windows testen

nslookup -querytype=SRV _xmpp-client._tcp.example.net
nslookup -querytype=SRV _xmpp-server._tcp.example.net

(wie das ergebnis aussieht hab ich gerade nicht greifbar)

heute thunderbird v15.0 installiert. man kann nun chats einbinden… hmm.. gleich mal ausprobieren. und natuerlich hats auf anhieb nicht geklappt. die fehlerkonsole sagt:

not authorized? passwort, benutzername und server/port alles richtig eingegeben.

und wie das immer so ist, findet man erstmal nichts, wenn man nach “brandneuen” problemen sucht. irgendwann bin ich auf einen ganz frischen eintrag in einem forum gestossen, der das problem erkannte:

We identified today the cause of the “Not authorized” error message for people connecting to OpenFire.
OpenFire doesn’t follow the standard DIGEST-MD5 exchange, and Thunderbird closes the connection when it receives something unexpected.

ahja.. der thunderbird mag also nicht mit meinem openfire reden. also dem openfire die DIGEST-MD5 methode zur authentifizierung abgewoehnen und alles ist gut. PLAIN login reicht mir vollkomen, da die verbindung ja sowieso verschluesselt ist. in der openfire.xml also diesen eintrag hinzufuegen:

PLAIN 

das muss in der config irgendwo zwischen diesen beiden tags stehen:

...

dienst neu starten und gut 🙂

und der facebook chat scheint auch zu funktionieren (auch jabber/xmpp basiert)… denn prompt kam ne nette video chat anfrage 😉

naja… vielleicht bauen die das ja auch noch in den thunderbird ein.

UPDATE: nachdem ich voller vorfreude den kram zum laufen gebracht habe, stelle ich fest: der chat client kann quasi nix. alles sehr rudimentaer gehalten.. aber scheint zu funktionieren.

wenn der openfire jabber server mal nicht mehr mag und im logfile oder webfrontend diese meldung spuckt:

java.lang.OutOfMemoryError: Java heap space.

dann muss der heap space einfach mal vergroessert werden. eine loesung habe ich gefunden:

Open the server script (/bin/openfire) in a text editor.

Search for a line starting with:

nohup “$app_java_home/bin/java” -server -Dinstall4j.jvmDir=”$app_java_home” (……)

Add the parameter -Xmx512m to increase the heap size (512 MB in this example). Like this:

nohup “$app_java_home/bin/java” -Xmx512m -server -Dinstall4j.jvmDir=”$app_java_home” (…..)

bloss was ist eine vernuenftige groesse? darauf suche ich noch eine antwort…

fast haette ich gedacht: “die habens kapiert” ….weil sie ihren nutzern zum chatten den offenen standard jabber bzw xmpp anbieten. sogar die nutzung “von draussen”, also mit einem normalen jabber client ist moeglich.

wenn man genauer hin sieht, dann ist das doch nicht so toll, was sie da anbieten.

wie beschrieben, ist kein SSL/TLS moeglich. aber warum leisten die sich nicht einfach mal ein zertifikat? das technische know how um das umzusetzen duerfte doch vorhanden sein. wenigstens ist keine plaintext authentication moeglich…

ich hab das mal mit meinem favorisierten client PSI ausprobiert. nach dem ersten login mit einem neuen account werde ich gebeten, meine “account information” zu setzen:

… leider wird dieses feature nicht unterstuetzt:

erstmal nicht tragisch, wenn der client psi mich nicht nach jedem login damit nerven wuerde. wenn jemand weiss, wie man das abstellen kann… immer her mit der info.

das manuelle setzen der resource ist zwar moeglich, aber facebook haengt dann hinten dran noch irgendeine ID:

es ist zwar moeglich, sich mehrfach einzuloggen, wobei aber auch die unterstuetzung mit der “resource” und der prioritaet nicht funktioniert. die nachrichten, die man bekommt, werden auf allen clients ausgegeben.

bis hier hin ist das alles noch nichts, was tragisch waere. das “FAIL” verdienen sie sich dadurch, dass die kommunikation nur mit facebook nutzern moeglich ist. also nur c2s (client-to-server) und kein s2s (server-to-server). auch die SRV records im dns fehlen (stand heute) gaenzlich. klar hat facebook natuerlich erstmal nur interesse daran, jabber fuer die eigene nutzung zu implementieren.

ich habe mir sagen lassen, dass google auch ca. ein halbes jahr gebraucht hat, um seine pforten zur aussenwelt zu oeffnen. facebook ist anscheinend etwas langsamer… die chat funktion existiert seit fast 2 jahren. ich vermute mal, dass diese von anfang an auf jabber basierte und bisher lediglich ueber das webinterface nutzbar war.

vielleicht wollen die das aber auch garnicht mit einer schnittstelle “nach aussen” anbieten? mometan sind automatisch alle “facebook freunde” in der “buddylist” bzw. dem “roaster”. wie wuerde das dann aussehen, wenn “normale” jabber kontakte dazu kaemen? wollen die user auch evtl. garnicht, dass facebook noch mehr ueber sie weiss? sich ist es besser, fuer die normale welt einen normalen jabber server zu nutzen. ich kann da z.b. jabber.schnied.net empfehlen. der server wird naemlich von mir betreut 😉

fazit: netter versuch. ein facebook junkie kann dieses feature bestimmt gebrauchen. aus sicht eines techies ist das ding noch nicht ausgereift. mal sehen, was noch passiert.

zum schluss noch ein netter kommentar zum posting ueber die oeffnung der pforten fuer jabber clients:

UPDATE: noch was zum technischen: um jabber zu nutzen und sich einloggen zu koennen muss man einen nickname anlegen. mit der facebook id klappt das nicht. user, die den webchat benutzen, sind allerdings mit einer jid nach dem muster uXXXXXXXXXX@chat.facebook.com unterwegs (wobei die X fuer die facebook id stehen).