Als E-Mail-Anbieter liegt es nahe auch einen Chatserver zu betreiben, und das größte öffentliche Chat-Netzwerk ist das Jabber-Netzwerk (auch XMPP-Netzwerk genannt, da das Protokoll XMPP heißt). Viele Anbieter bieten ihren Kunden auch einen Jabber-Server-Zugang, der automatisch die selben Zugangsdaten hat wie das E-Mail-Postfach, man kann ihn also sofort nutzen. Doch schaut man sich im Detail an was das für Jabber-Server sind und wie sie konfiguriert sind, dann stellen sich einem die Haare zu Berge. Einige kümmern sich anscheinend darum, auf dem neuesten Stand zu sein, Verschlüsselung richtig anzubeiten usw, und andere scheint das mal wieder nicht zu interessieren. Völlig veraltete Protokolle und Verschlüsselungsalgorithmen werden angeboten, man kann also gut sehen wer sich für die Sicherheit seiner Kunden interessiert und wer nicht.
Im Mai diesen Jahres wurden alle Jabber-Server-Anbieter dazu aufgerufen STARTTLS zur Pflicht zu machen, sodass man nicht ausversehen mit seinem Jabber-Programm eine unverschlüsselte Verbindung öffnen kann, und auch die Jabber Server untereinander nur noch verschlüsselt kommunizieren. Doch leider zieht ein großer Anbieter nicht mit: Google. Googles Jabber-Server (bzw. XMPP-kompatibler Server für Hangouts) bietet gar keine Verschlüsselung bei der Server-to-Server Kommunikation. Jeder Anbieter, der bei der S2S-Verbindung also STARTTLS zur Pflicht macht, schneidet seine Nutzer von anderen Jabber-Nutzern ab die bei Google online sind. Das hält (zurecht) viele davon ab dort das Häkchen zu setzen, sodass es vorerst bei der optionalen Verschlüsselung bleibt (wenn beide Server es unterstützen, wird verschlüsselt, was außer bei Google eigentlich bei allen Jabber-Servern der Fall ist).
In der folgenden Tabelle steht C2S für die Client-to-Server Verbindung, also vom Jabber-Programm beim Kunden zum Jabber-Server beim Anbieter. S2S steht hingegen für die Server-to-Server Verbindung zwischen zwei Jabber-Servern.
Hier nun die Ergebnisse:
Zertifikate | Protokolle | Ciphers | STARTTLS | TLSA(DANE) | Tests | |
---|---|---|---|---|---|---|
mail.de | C2S: gültig S2S: gültig | C2S: TLSv1, TLSv1.1, TLSv1.2 S2S: TLSv1, TLSv1.1, TLSv1.2 | C2S: modern, incl. PFS S2S: modern, incl. PFS | C2S: Pflicht S2S: optional | ja ja | C2S: A S2S: A |
Freenet | C2S: gültig S2S: gültig | C2S: SSLv3, TLSv1, TLSv1.1, TLSv1.2 S2S: SSLv3, TLSv1, TLSv1.1, TLSv1.2 | C2S: schwach, kein PFS S2S: schwach, kein PFS | C2S: optional S2S: optional | nein nein | C2S: A- S2S: A- |
GMX | C2S: ungültig S2S: ungültig | C2S: SSLv2, SSLv3, TLSv1 S2S: SSLv2, SSLv3, TLSv1 | C2S: schwach, kein PFS S2S: schwach, kein PFS | C2S: optional S2S: optional | nein nein | C2S: F S2S: F |
web.de | C2S: ungültig S2S: ungültig | C2S: SSLv2, SSLv3, TLSv1 S2S: SSLv2, SSLv3, TLSv1 | C2S: schwach, kein PFS S2S: schwach, kein PFS | C2S: optional S2S: optional | nein nein | C2S: F S2S: F |
1und1 | C2S: ungültig S2S: ungültig | C2S: SSLv2, SSLv3, TLSv1 S2S: SSLv2, SSLv3, TLSv1 | C2S: schwach, kein PFS S2S: schwach, kein PFS | C2S: optional S2S: optional | nein nein | C2S: F S2S: F |
GMail | C2S: gültig S2S: - | C2S: SSLv3, TLSv1, TLSv1.1, TLSv1.2 S2S: - | C2S: schwach, kein PFS S2S: - | C2S: Pflicht S2S: - | nein nein | C2S: A- S2S: - |
GMail habe ich an das Ende gestellt weil sie bei der Server-to-Server Verbindung gar keine Verschlüsselung unterstützen, was meines Erachtens noch schlechter ist als eine schlecht konfigurierte Verschlüsselung.
DANE/TLSA habe ich bereits im vorletzten Artikel beschrieben, Anbieter die es nutzen sind sicherer durch den Einsatz von DNSSEC.
Mir sind keine anderen großen E-Mail-Anbieter bekannt die einen Jabber-Server anbieten…