Jul 29

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.

C2S und S2S erklärt

Hier nun die Ergebnisse:

ZertifikateProtokolleCiphersSTARTTLSTLSA(DANE)Tests
mail.deC2S: 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
FreenetC2S: 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-
GMXC2S: 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.deC2S: 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
1und1C2S: 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
GMailC2S: 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…

Tagged with:
Jul 15

Einige Nutzer melden uns, dass Posteo seit heute morgen nicht mehr erreichbar ist. Laut Twitter und deren Status-Seite liegt seit 8:50 Uhr ein Problem mit der Stromversorgung vor.

Wie uns die Nutzer berichten, häufen sich die Ausfälle/Störungen in den letzten Monaten. Auch auf allestörungen.de sind einige Einträge nachzulesen, die die Häufigkeit der Störungen belegen.

Auch nach 3 Stunden ist der Dienst noch nicht wieder erreichbar.

Update: Nach 6 Stunden ist Posteo wieder erreichbar. Komisch ist die “Netzkonfiguration”, die fast 3 Stunden gedauert hat. Was genau soll das sein?

Posteo offline

Tagged with:
Jul 04

Vor kurzem machten zwei E-Mail-Anbieter von sich reden, die sicherheitstechnisch aufrüsten und nun DANE anbieten. Doch was ist DANE im Detail, und warum ist das eine gute Idee?

Ein großes Problem ist dass E-Mails nicht zwingend verschlüsselt übertragen werden. Die beteiligten Mailserver, zwischen denen E-Mails ausgetauscht werden, sprechen sich ab und wenn beide Verschlüsselung beherrschen, dann wird der Transportweg abgesichert. Und da tritt direkt das nächste Problem auf: Mailserver verwenden häufig keine gültigen Zertifikate. Aus diesem Grund werden häufig selbst-signierte Zertifikate verwendet, es gibt Mailserver mit abgelaufenen Zertifikaten, oder bei den Zertifikaten passt der Servername nicht. Alles Gründe, weshalb ein Browser eine Warnung anzeigen würde. Aber bei automatisierten Systemen wie Mailservern kann man keine Warnung anzeigen, man könnte höchstens die E-Mail nicht zustellen. Das jedoch würde dafür sorgen dass ziemlich viele E-Mails nicht zugestellt werden würden, weshalb heutzutage alle Mailserver jedes präsentierte Zertifikat annehmen und es zur Verschlüsselung verwenden. Sollte ein Angreifer also das Zertifikat auf dem Weg austauschen würde das niemand merken.

Und genau dort kommt DANE ins Spiel. DANE ist ein Verfahren, um Zertifikats-Informationen über einen Dienst aus dem DNS-System zu holen. Ein Mailserverbetreiber kann im DNS-System einen sogenannten TLSA-Eintrag hinterlegen, der einen Hash eines Zertifikats enthält. Ein sendender Mailserver, der DANE beherrscht, fragt also vor dem Verbindungsaufbau zu Anbieter B im DNS-System nach, ob der Anbieter B Zertifikatsinformationen für seine Mailserver hinterlegt hat in einem TLSA-Eintrag. Sollte das der Fall sein, wird diese Information genommen und mit dem eigentlichen Verbindungsaufbau verglichen. Sollte ein Angreifer nun das Zertifikat des Mailservers austauschen, würde dies auffallen und die E-Mail würde nicht versendet werden. Ebenso wird eine sogenannte Downgrading-Attacke vermieden, bei dem ein Angreifer in die Verbindung eingreift und die Fähigkeit der Verschlüsselung unterdrückt, sodass die E-Mail in diesem Fall unverschlüsselt übertragen werden würde. Sollte der Mailserver-Betreiber aber einen TLSA-Eintrag im DNS-System hinterlegt haben, so würde in diesem Fall die E-Mail gar nicht versendet werden, eine Klartextübertragung ist ausgeschlossen.

Doch ein Angreifer könnte ja auch, da er die Verbindungen des Opfers manipulieren kann, auch die DNS-Antworten verändern, und dort einen gefälschten TLSA-Eintrag an das Opfer senden. Deshalb ist es Pflicht, dass die DNS-Antworten signiert werden müssen, und diese Signatur muss auch überprüft werden. Dazu gibt es seit einigen Jahren DNSSEC, eine Signierung von DNS-Antworten, um Manipulationen im DNS-System zu verhindern.

Wenn also DNSSEC und TLSA-Einträge zusammenkommen, kann man Mailserververbindungen absichern. Und nicht nur das, jegliche Protokolle können damit abgesichert werden, zum Beispiel auch HTTPS, SMTP, IMAP, POP3, Jabber und weitere. Wichtig ist dabei nur dass der Verbindungspartner auch DANE unterstützt, was jedoch noch sehr wenige sind.

Hier eine Übersicht einiger E-Mail-Anbieter, die DNSSEC und DANE beherrschen:

AnbieterDNSSECDANEProtokolleBesonderheiten
mail.de++MX, HTTPS, SMTP, IMAP, POP3, CalDAV, CardDAV, WebDAV, JabberAuch alle Alias-Domains sind gesichert
posteo.de++MX, HTTPSKeine der Alias-Domains ist gesichert
GMX---
web.de---
Freenet---
T-Online---
Gmail---
Yahoo---
kabelmail.de---
ok.de---
outlook.com---
iCloud---
Arcor---
emailn.de---

Wie man sieht ist DANE leider noch nicht sehr weit verbreitet. Das liegt auch daran dass DNSSEC leider noch nicht sehr weit verbreitet sind bei den Domainhostern.

Jeder Mailserverbetreiber kann selbst recht einfach ausgehend DANE nutzen, dazu ist kein spezieller Domainhoster nötig. Alles was nötig ist ist ein DNSSEC-fähiger DNS-Resolver, und beispielsweise Postfix in Version 9.11.0 oder neuer. Dann noch DANE aktivieren, und schon wird bei versendeten E-Mails nach TLSA-Einträgen im DNS-System des Empfängers nachgeschaut.

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_loglevel = 1

Als Endnutzer kann man sich mit Hilfe eines Browser-Addons die DNSSEC-und TLSA-Unterstützung anzeigen lassen für Webseiten. Das Addon für Chrome, Firefox, Internet Explorer, Opera und Safari zeigt mit Hilfe von grünen Icons an ob die Webseite sicher ist oder nicht.

DNSSEC TLSA Validator

Warten wir mal ab bis mehr Anbieter mitziehen. Leider scheinen einige sich abzukapseln und ein ähnliches System umzusetzen, genannt “E-Mail Made in Germany”. Zu diesem Club können sich nur deutsche Firmen anmelden, es gilt also nicht weltweit. Es kostet ca. 30.000€ dort beizutreten, kleine Mailanbieter oder private Mailserverbetreiber sind somit ausgeschlossen. Außerdem müssen dort manuell Textdateien mit Zertifikatsinformationen ausgetauscht werden. Mit DANE und TLSA-Einträgen hat man all diese Nachteile nicht, die eindeutig bessere Wahl.

Tagged with:
Jun 17

Servicewüste Deutschland, dieses Vorurteil hört man immer wieder. Doch stimmt das auch für E-Mail-Anbieter? Ich habe versucht für alle gängigen E-Mail-Anbieter die Kontaktmöglichkeiten bei Problemen oder Fragen herauszufinden, gesucht habe ich nach E-Mail-Adressen, Telefonnummern, einem Twitter- und Facebookaccount. Hier meine Rechercheergebnisse vom 11.06.2014 (bitte in die Kommentare schreiben falls ihr Lücken füllen könnt):

RangAnbieterper E-Mailper Telefonper Twitterper Facebook
1mail.desupport@mail.de05241 74 34 982 (Festnetztarif)@mail_demail.de
2Freenetsupport@freenet.de0900 1750850 (0,14€ bis 1,29€)Nicht gefundenfreenetMail
3GMXkein Support per E-MailFreeMail: 0900 1000 877 (3,99€ pro Anruf)
Pro- oder TopMail: 0721 960 99 99 (Festnetztarif)
GMXGMXde
4web.dekein Support per E-MailFreeMail: 0900 1 93 23 30 (3,99€ pro Anruf)
web.de Club: 721 960 99 97 (Festnetztarif)
WEBDEWEB.DE
5Yahookein Support per E-Mail001 800 318 0612 (nur Roboter, amerikanische Nummer)@YahooCareYahooCustomerCare
6Posteosupport@posteo.dekein Support per Telefon@Posteo_denicht auffindbar
7GMailkein Support per E-Mailkein Support per TelefongmailGmail
8Outlook.comkein Support per E-Mailkein Support per Telefon@Outlookoutlook
9T-Onlinekein Support per E-Mailkein Support per Telefon@Telekom_hilfttelekomhilft

3,99€ pro Anruf finde ich eine Frechheit. Kein Support per E-Mail finde ich für einen E-Mail-Anbieter auch sehr ungewöhnlich.

Die Twitter- und Facebook-Accounts von der Telekom sind sicherlich zu loben, dort wird einem geholfen, aber seine Fragen nur öffentlich stellen zu können mag auch in diversen Situationen abschreckend sein, ein persönlicher Weg per E-Mail oder Telefon wäre sicherlich hilfreich in einigen Fällen.

Yahoo bietet zwar ausführliche Hilfeseiten, aber rein englische Twitter- und Facebookseiten sowie einen englischen Telefonroboter unter einer amerikanischen Telefonnummer dürfte auch viele Nutzer abschrecken.

Tagged with:
Mrz 24

E-Mail-Verschlüsselung zwischen E-Mail-Providern ist optional, die beiden beteiligten Mailserver sprechen sich ab ob sie beide verschlüsseln können, und wenn ja mit welchem Verschlüsselungsalgorithmus und welcher Schlüssellänge die Verbindung abgesichert wird.

Hier eine kleine Tabelle mit einigen Ergebnissen vom Online-Dienst starttls.info. Diese Webseite testet den empfangenden Mailserver auf Verschlüsselungsfeatures:

AnbieterPunkteProtokolleSchlüssellängeChiffre
GMail90,6%Supports SSLV3.
Supports TLSV1
Supports TLSV1.1
Supports TLSV1.2
2048bit128-256bit
mail.de90,6%Supports SSLV3.
Supports TLSV1
Supports TLSV1.1
Supports TLSV1.2
2048bit128-256bit
GMX90,6%Supports SSLV3.
Supports TLSV1
Supports TLSV1.1
Supports TLSV1.2
2048bit128-256bit
web.de90,6%Supports SSLV3.
Supports TLSV1
Supports TLSV1.1
Supports TLSV1.2
2048bit128-256bit
T-Online86,8%Supports TLSV12048bit128-168bit
Yahoo83,2%Supports SSLV3.
Supports TLSV1
2048bit128-256bit
kabelmail.de83,2%Supports SSLV3
Supports TLSV1
2048bit128-256bit
Freenet79,2%Supports SSLV3.
Supports TLSV1
Supports TLSV1.1
Supports TLSV1.2
2048bit40-256bit
emailn.de73,2%Supports SSLV3.
Supports TLSV1
Supports TLSV1.1
Supports TLSV1.2
selbstsigniert
2048bit
56-256bit
ok.de40,5%Supports SSLV3
Supports TLSV1
Anonymous Diffie-Hellman
2048bit
0-168bit
Arcor37,6%Supports SSLV2
Supports SSLV3
Supports TLSV1
Anonymous Diffie-Hellman
2048bit
0-256bit
mailde.de31,6%Supports SSLV2
Supports SSLV3
Supports TLSV1
selbstsigniert
Hostname stimmt nicht
Anonymous Diffie-Hellman

2048bit
0-256bit
outlook.com0%---
icloud.com0%---

Einige Anbieter legen nach wie vor nicht die nötige Priorität auf die Verschlüsselung, auch Monate nach den Snowden-Informationen und mit dem Wissen dass Geheimdienste und andere Interessierte unsere Daten abhören und mitschneiden gibt es dort kein Mindestmaß an Sicherheit. Aber im Vergleich zu 2012 haben einige nachgebessert, wenn auch noch nicht das maximal mögliche rausgeholt wird.

Mehr als 90,6% kann man übrigens nur bekommen indem man ältere Protokolle wie z.B. SSLv3 oder TLSv1 abschaltet. Das jedoch kann sich kein Anbieter erlauben da dann einige E-Mails nicht mehr zugestellt werden könnten. Es gibt da draußen in der Welt leider noch einige ältere Mailserver die nur maximal SSLv3 unterstützen, sodass diese dann außen vor bleiben würden, und das will man aktuell noch nicht solange SSLv3 noch nicht als gebrochen gilt. Es bröckelt zwar in den letzten Jahren hier und da leicht, gilt aber noch als sicher.

Tagged with:
preload preload preload