Schlagwort: Jabber

Mein Jabber-Server, und was das IM Observatory dazu meint

Die mei­nen: schlecht.
Cli­ent bzw. Ser­ver
Weiß jemand, wie ich die schwa­chen Cipher weg­be­kom­me? Das ist ein Open­fire unter

# java -version
openjdk version "1.8.0_60"
OpenJDK Runtime Environment (build 1.8.0_60-b27)
OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode)
#

jdk.tls.disabledAlgorithms in java.security zu set­zen hat jeden­falls nicht zum Erfolg geführt.
Und nmap läßt mich zwei­feln, ob die Web­site wirk­lich Recht hat:

~$ nmap --script ssl-enum-ciphers -p 5222 xmpp.sokoll.com

Starting Nmap 6.47 ( http://nmap.org ) at 2015-10-27 18:35 CET
Nmap scan report for xmpp.sokoll.com (195.110.60.28)
Host is up (0.040s latency).
rDNS record for 195.110.60.28: allinclusive.sokoll.com
PORT STATE SERVICE
5222/tcp open xmpp-client
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.1:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| compressors:
| NULL
| TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| compressors:
| NULL
|_ least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 9.16 seconds
~$

XMPP/Jabber, jetzt aber richtig

Mein Jabber-Ser­ver (open­fire) hat­te ein selbst­si­gnier­tes Zer­ti­fi­kat, noch dazu im Okto­ber abge­lau­fen.
Und da Flo­ri­an einen Kon­takt auf jabber.ccc.de hat, der aber nicht ging, war es Zeit, das rich­tig zu machen.
Also habe ich mir einen CSR erzeugt und den bei startssl.com ein­ge­kippt. Die gaben mir dann freund­li­cher­wei­se ein Clas­s1-Zer­ti­fi­kat zurück — und nun begann der Kampf. Open­fire ist java, und das hat für das gesam­te Key­ma­nage­ment ein Drecks­tool namens key­tool. Nach Stun­den habe ich es dann doch hin­be­kom­men, die Zer­ti­fi­ka­te ein­zu­bau­en.

Man benö­tigt das Zer­ti­fi­kat natür­lich, dazu noch das Zwi­schen­zer­ti­fi­kat von starts­sl, das es hier gibt.
Wir wech­seln nach /opt/openfire/resources/security.
Dann wer­den die bei­den Zer­ti­fi­ka­te zusam­men­ge­wor­fen:

cat /etc/ssl/private/xmpp.sokoll.com.startssl.crt /etc/ssl/private/sub.class1.server.ca.pem > xmpp.pem

Und jetzt kommt der gro­ße Trick: key­tool kann zwar PEM-Zer­ti­fi­ka­te impor­tie­ren, aber kei­ne pri­va­ten Keys. Also muß ein Bund­le aus den bei­den Zer­ti­fi­ka­ten und dem pri­va­ten Key im PKCS#12-Format erzeugt wer­den, dafür neh­me ich opens­sl:

openssl pkcs12 -export -in xmpp.pem -inkey /etc/ssl/private/xmpp.sokoll.com.startssl.key -out xmpp.p12

Den alten key­s­to­re habe ich ein­fach mit rm key­s­to­re weg­ge­wor­fen.
Nun kön­nen wir auch einen neu­en key­s­to­re mit pri­va­tem Key und den bei­den Zer­ti­fi­ka­ten erzeu­gen:

keytool -importkeystore -deststorepass changeit -destkeypass changeit -srckeystore xmpp.p12 -srcstoretype PKCS12 -srcstorepass changeit -srcalias 1 -destalias sokoll.com -destkeystore keystore

Ja, das Paß­wort zu mei­nem key­s­to­re lau­tet “chang­eit”, falls jemand das braucht 😉
Open­fire neu­star­ten, die neu­en Zer­ti­fi­ka­te soll­ten in der Admin-UI auf­tau­chen.

Soweit, so gut, gleich mal nach­se­hen, wie das von außen aus­sieht. So. viel grün, könn­te aber grü­ner sein 🙂 Das “Warning: Ser­ver allows RC4 when using TLS 1.1 and/or TLS 1.2. Gra­de cap­ped to A-.” stört aber. RC4 will man mei­nes Wis­sens nicht. Und SSLv3 will man nach Pood­le auch nicht, wenn auch das für XMPP irrele­vant sein dürf­te.
Doch wo stellt man das aus? Hm, in der JRE, bei mir in /usr/lib64/jvm/java-1.7.0-openjdk-1.7.0/jre/lib/security/java.security. Ich habe ans Ende ein­fach ein jdk.tls.disabledAlgorithms=RC4, MD5, SHA1, DSA, RSA key­Si­ze < 2048 dran­ge­pappt, und ja, es sieht bes­ser aus.
Aller­dings sieht es so gut aus, daß mein Cli­ent (Jit­si) sich nicht mehr ver­bin­den mag — wahr­schein­lich wegen des feh­len­den TLSv1.1.
Für Tipps, wie ich das hin­ein­be­kom­me, aber ohne SSLv3, bin ich dank­bar.

© Rainer Sokoll Frontier Theme