JUNe/SSL/TLS

Aus RWTH Jabber

Dieser Artikel wird von den am Jabber University Network beteiligten Universitäten gemeinsam verwendet. Aus diesem Grund ist der Artikel allgemein gehalten und nicht spezifisch für eine bestimmte Universität. Dadurch sparen wir eine Menge Arbeit und können euch insgesamt eine umfangreichere Dokumentation bieten.

[Bearbeiten] Transport Layer Security (SSL/TLS)

SSL ist eine sehr einfach zu bedienende, weit verbreitete Verschlüsselung. TLS ist der Nachfolger von SSL und sollte daher bevorzugt werden. Beides wird häufig in Form des HTTPS-Protokolls eingesetzt um Webseiten (z.B. beim Online-Banking) zu verschlüsseln. Die meisten Jabber-Programme unterstützen eine SSL- oder TLS-Verschlüsselung, jedoch ist diese häufig standardmäßig deaktiviert. Normalerweise sollte es reichen irgendwo in den Optionen einen entsprechenden Haken zu setzen.

Damit ist nun die Verbindung vom Client (Chat-Programm) zum Jabber-Server verschlüsselt. Sofern die Verbindung einmal korrekt aufgebaut wurde, ist ein mitschneiden der Daten an einer Zwischenstation sinnlos geworden. Der Server selbst kann weiterhin alle Daten lesen, verarbeiten oder weiterleiten. Die verschlüsselte Verbindung endet am Server. Damit also die Verschlüsselung vollständig ist, müssen natürlich auch alle Kontakte mit denen man kommunizieren möchte ebenfalls die SSL/TLS-Verschlüsselung aktivieren. Die Verbindung zwischen verschiedenen Jabber-Servern (wenn man mit Kontakten auf anderen Servern chattet) sollte ebenfalls verschlüsselt sein. Leider ist dies selten der Fall, auch wenn beide Server SSL/TLS unterstützen. Darauf hat man als einfacher User aber keinen Einfluss.

Die einzigen übrig gebliebenen Angriffspunkte sind, neben dem eigenen Rechner, die beteiligten Server. Auf jedem Server wird das Datenpaket entschlüsselt und kann vom Betreiber des Servers gelesen werden. Vertraut den beteiligten Servern nicht, so muss man zur nächsten Stufe greifen: Einer Ende-zu-Ende-Verschlüsselung, z.B. mit OpenPGP oder OTR. Vertraut man auch dem eigenen Rechner nicht hat man ein Problem, den dagegen hilft auch die beste Verschlüsselung nichts.

Die SSL-Verschlüsselung selbst gilt bisher als sicher, ist aber nicht unangreifbar. Ich möchte hier auf die Technik nicht weiter eingehen, jedoch sei soviel gesagt, dass man nicht einfach so irgendwelche SSL-Zertifikate akzeptieren sollte. Zeigt einem ein Mann in Polizeiuniform einen einfachen Zettel auf dem steht "Dieser Mann ist ein Polizist" und behauptet dies wäre sein Dienstausweis, glaubt man diesem ja auch nicht. Dies ist auch der Grund warum Server-zu-Server Verbindungen selten verschlüsselt sind: Auf beiden Servern müssten gegenseitig die Zertifikate installiert werden. Dies wäre bei der riesigen Anzahl an Jabber-Servern unmöglich, zumal ein großer Server (z.B. GoogleTalk) sich sicherlich nicht damit abgeben wird, die Schlüssel eines mittelgroßen Uni-Servers zu installieren. Mehr zur technischen Funktionsweise von SSL/TLS findet sich bei Wikipedia.

[Bearbeiten] Importieren des SSL/TLS-Zertifikats

Will man die volle Sicherheit von SSL/TLS, so sollte man das Zertifikat des Servers importieren auf dem sich der eigene Account befindet. Dadurch wird gewährleistet, dass man auch wirklich mit dem richtigen Server verbunden ist. Dabei muss man sicherzustellen, dass man das richtige Zertifikat installiert und sich nicht etwa das gefälschte Zertifikat eines Angreifers. Daher sollte man unbedingt den Fingerprint überprüfen. Kommt nach dem installieren des korrekten Zertifikats noch eine Warnung, so sollte man diese sehr ernst nehmen!

Installiert man die Zertifikate nicht, wird sich möglicherweise das Chat-Programm beim Verbindungsaufbau mit einer Warnung beschweren. Einige Programme geben eine solche Warnung gar nicht erst aus bzw. bieten eine Option diese zu ignorieren. Tut man dies, ist es möglich die Verschlüsselung (mit einigem Aufwand) auszuhebeln.

Das SSL/TLS-Zertifikat deines Jabber-Servers wirst du in der Regel irgendwo auf dessen Webseite finden. Je nach Server kann es sein das du mehrere Zertifikate installieren musst. Die Zertifkate der an JUNe beteiligten Universitäten sind hier aufgelistet:

Universität	Link zur Zertifikatseite
RWTH Aachen	https://jabber.rwth-aachen.de/index.php?function=cert
FH-BRS	https://www5.inf.fh-bonn-rhein-sieg.de/FAQ/misc/rca

[Bearbeiten] Adium

Der für OSX verfügbare Multimessenger greift auf den OSX eignen Keystore zu. Um dort ein Cert einzufügen läd man es im pem Format herrunter und doppelklickt auf das Zertifikat. In der sich öffnenden "Schlüsselbundverwaltung" akzeptiert man, natürlich nach Prüfung, das Zertifikat.

[Bearbeiten] Psi

Seit Psi 0.11 wird das Zertifikat endlich im üblichen PEM-Format akzeptiert. Es reicht einfach alle benötigten PEM-Dateien mit den Zertifikaten in einem Ordner certs im Benutzerverzeichnis von Psi zu kopieren. Ist der Ordner noch nicht vorhanden kann man ihn einfach erzeugen. Nach dem kopieren der Datei die SSL-Warnungen wieder einschalten und erneut mit dem Server verbinden.

Linux, MacOS und andere Unix

~/.psi/certs

Windows NT, 2000, XP und Server 2003

%UserProfile%\PsiData\certs

( normalerweise C:\Dokumente und Einstellungen\Benutzername\PsiData\certs )

Windows 95, 98 und Me

%ProgramFiles%\Psi\PsiData\certs

( normalerweise C:\Programme\Psi\PsiData\certs )

[Bearbeiten] Jabbin

Jabbin bassiert auf Psi, daher sollte das dort ähnlich funktionieren. Wäre schön wenn das jemand bestätigen könnte.

[Bearbeiten] Kopete (KDE 3)

Theoretisch: Einfach mit dem Konqueror-Browser die Zertifikat-Datei öffnen, den Fingerprint überprüfen und auf Importieren klicken. Das Zertifikat wird dadurch für alle KDE-Programme verfügbar, also auch für Kopete. Alternativ kann man das Zertifikat auch im Kontrollzentrum importieren. (Falls die notwendigen Pakete für die SSL-Verschlüsselung nicht installiert sind, so beschwert sich Jabber beim ersten Login-Versuch über ein fehlendes SSL, bzw. QCA TLS Modul. Das Paket, das nachinstalliert werden muss, heißt bei den meisten Distributionen qca-tls.)

Praktisch: Obwohl das KDE-Kontrollzentrum und Konqueror bestätigen, dass alles in Ordnung ist, behauptet Kopete die Zertifizierungsstelle wäre ungültig. Es handelt sich wahrscheinlich um diesen Kopete-Bug: http://bugs.kde.org/show_bug.cgi?id=144912

Natürlich kann man die Warnung auch ignorieren, aber dann kann man sich das importieren des Zertifikats auch sparen. Wenn jemand eine Lösung/Workaround findet bitte melden. --Coolcat 14:05, 21. Jul 2007 (CEST)

[Bearbeiten] Kopete (KDE 4)

Sicherstellen, dass das QCA OSSL plugin for libqca2 sowie Kleopatra installiert sind. Die zu installierenden Pakete heißen bei den meisten Distributionen libqca2-plugin-ossl und kleopatra. Dann das benötigte Zertifikat (bzw. die benötigten Zertifikate) mit Kleopatra importieren. Dazu reicht es aus, die Zertifikat-Datei einfach im Dateimanager zu öffnen.

[Bearbeiten] mcabber

Um das Server-Zertifikat durch mcabber überprüfen zu lassen, speichert man alle benötigten Zertifikate im PEM-Format dort, wo man auch andere CA-Zertifikate speichert, oder an einer Extra-Stelle nur für mcabber, z.B. im Verzeichnis

~/.mcabber/ca

Das Verzeichnis muss man evtl. selber vorher anlegen.

Wenn alle benötigten Zertifikate in dem Verzeichnis liegen, muss das Verzeichnis mit cacertdir_rehash oder c_rehash bearbeitet werden:

cacertdir_rehash ~/.mcabber/ca

Bei Fedora 7 gehört cacertdir_rehash zum Paket authconfig. Da rehashen erzeugt im selben Verzeichnis ein paar symbolische Links auf die Zertifikate, damit mcabber diese finden kann.

Nun kann man mit folgenden Optionen mcabber dazu bewegen, das Serverzertifikat zu überprüfen:

set ssl = 1
set ssl_verify = -1
set ssl_capath = ~/.mcabber/ca

[Bearbeiten] iChat

Die Einrichtung ist im iChat-Artikel beschrieben.

[Bearbeiten] Pidgin

Pidgin 2.5.1 kann Zertifikate selbstständig importieren. Beim ersten Login auf dem Server erscheint eine Meldung bei der man das Zertifikat akzeptieren kann. Bevor man das Zertifikat akzeptiert sollte man den Fingerprint prüfen.

Alternativ kann man einfach alle benötigten PEM-Dateien mit den Zertifikaten in das Verzeichniss certificates im Benutzerverzeichnis von Pidgin zu kopieren:

Linux, MacOS und andere Unix: ~/.purple/certificates

[Bearbeiten] Gajim / Miranda / Trillian

Von Gajim, Miranda und Trillian werden Zertifikate leider gar nicht erst geprüft. Die SSL/TLS-Verschlüsselung kann hier also von einem Angreifer ausgehebelt werden. Auch die Gajim Entwickler arbeiten an einem SSL certificate verification feature.

[Bearbeiten] Fingerprint

Um sicherzustellen, dass man das richtige Zertifikat installiert und sich nicht etwa das gefälschte Zertifikat eines Angreifers, sollte man den Fingerprint überprüfen. Dabei handelt es sich um einen Hashwert des Schlüssels, also eine Art Fingerabdruck der man vergleichsweise schnell von Hand vergleichen kann.

Sofern möglich sollte man den Fingerprint über einen anderen Kommunikationskanal beziehen, als den über den man das Zertifikat erhalten hat. Idealerweise macht man das mündlich oder per Telefon. Hat es nämlich jemand geschafft jemanden einen gefälschten Schlüssel unterzujubeln, so schafft er es auch mit dem Fingerprint.

Es gibt verschiedene Fingerprints, üblich sind MD5 und SHA-1. Sofern nicht der Jabber-Client selbst in der Lage ist den Fingerprint anzuzeigen, kann man den Fingerprint leicht mit folgendem Befehl aus einem Zertifikat generieren:

openssl x509 -noout -md5 -fingerprint -inform PEM -in zertifikat-datei.pem

bzw.

openssl x509 -noout -sha1 -fingerprint -inform PEM -in zertifikat-datei.pem

Das Ergebnis vergleicht man dann mit dem Fingerprint des Keys den man importieren wollte.

Hinweis: Unter Windows ist das Programm OpenSSL normalerweise nicht vorinstalliert. In der Regel muss man es aber sowieso installieren, da viele Jabber-Clients openssl benutzen.

Hinweis: Beim Fingerprint handelt es sich um den Hashwert des Zertifikats im DER-Format, daher lässt sich der Fingerprint mit den Programmen md5sum bzw. sha1sum nur aus der DER-Datei berechnen.