Nov 19

Seit August 2018 ist TLS 1.3 verabschiedet, und damit ein offizieller Internet-Standard (RFC 8446). Die neue Version des Verschlüsselungsprotokolls bietet moderne Sicherheitsfeatures und bessere Performance als TLS 1.2 (und als 1.1 und 1.0 sowieso).

Welche großen E-Mail-Anbieter bieten ihren Kunden bereits TLS 1.3 an? Hier eine Übersicht (Stand 19.11.2018):

E-Mail-AnbieterTLS-VersionenGetestete DomainGesamtnote SSLLabs
mail.deTLS 1.3
TLS 1.2
TLS 1.1
TLS 1.0
mail.deA+
GMailTLS 1.3
TLS 1.2
TLS 1.1
TLS 1.0
mail.google.comA
mailbox.orgTLS 1.2mailbox.orgA+
PosteoTLS 1.2
TLS 1.1
TLS 1.0
posteo.deA+
GMXTLS 1.2
TLS 1.1
TLS 1.0
gmx.deA+
web.deTLS 1.2
TLS 1.1
TLS 1.0
web.deA+
YahooTLS 1.2
TLS 1.1
TLS 1.0
de.yahoo.comA+
T-OnlineTLS 1.2
TLS 1.0
t-online.deA
Outlook.comTLS 1.2
TLS 1.1
TLS 1.0
outlook.live.comA
FreenetTLS 1.2
TLS 1.1
TLS 1.0
freenet.deA

mail.de und Gmail sind die einzigen, die 3 Monate nach Verabschiedung des Standards bereits TLS 1.3 anbieten.

Wie man sieht, niemand erlaubt sich einen Patzer und unterstützt noch SSL 3.0. mailbox.org sticht heraus, da bereits TLS 1.0 und 1.1 abgeschaltet wurden (was gut ist!).

Für den Test habe ich die jeweiligen Webseiten der Anbieter mit dem SSL-Server-Test von SSLLabs analysiert:
https://www.ssllabs.com/ssltest/index.html

Wenn ich etwas mehr Zeit habe, werde ich auch die anderen Protokolle (IMAP, POP3, SMTP) prüfen, ob TLS 1.3 angeboten wird oder nicht.

 

Apr 21

Heute wurde bei heise Netze eine Testwebseite vorgestellt die Dinge wie IPv6-Unterstützung, DKIM, SPF, DMARC und DNSSEC überprüft und die Ergebnisse bewertet. Hier die aktuellen Ergebnisse:

AnbieterPunkteLink
mail.de100%https://en.internet.nl/mail/info%40mail.de/results
mailbox.org73%https://en.internet.nl/mail/info%40mailbox.org/results
posteo.de62%https://en.internet.nl/mail/info%40posteo.de/results
GoogleMail47%https://en.internet.nl/mail/info%40googlemail.com/results
Yahoo47%https://en.internet.nl/mail/info%40yahoo.com/results
iCloud42%https://en.internet.nl/mail/info%40icloud.com/results
Outlook.com40%https://en.internet.nl/mail/info%40outlook.com/results
GMX36%https://en.internet.nl/mail/info%40gmx.de/results
web.de36%https://en.internet.nl/mail/info%40web.de/results
Freenet36%https://en.internet.nl/mail/info%40gfreenet.de/results
Arcor31%https://en.internet.nl/mail/info%40arcor.de/results
T-Online18%https://en.internet.nl/mail/info%40t-online.de/results
Tagged with:
Okt 15

Heute Nacht wurde eine Sicherheitslücke in SSLv3 mit dem Namen Poodle veröffentlicht, mit deren Hilfe ein Angreifer die verschlüsselte Verbindung abhören kann. Da das Problem ein Fehler im Protokolldesign ist kann es nicht behoben werden, die einzige Maßnahme ist die Abschaltung dieses alten Protokolls.

SSLv3 ist 18 Jahre alt, und wurde von 15 Jahren durch TLS 1.0 ersetzt. Trotzdem gibt es noch Programme die SSLv3 als „bestes“ Verschlüsselungsprotokoll unterstützen, eine Abschaltung bedeutet für diese alten Programme, dass sie nicht mehr auf die Webseite zugreifen können, da sich die beiden Kommunikationspartner nicht auf ein gemeinsames Protokoll einigen können.

Betroffen ist bei einer solchen serverseitigen Abschaltung von SSLv3 vor allem der Internet Explorer 6 unter Windows XP. Beides sollte man nicht mehr einsetzen, es ist also nicht wirklich ein Problem wenn diese Uraltsysteme dann Probleme haben. Man spricht von ca. 0.3% der Verbindungen die betroffen sind, also vergleichsweise wenige. Wäre z.B. TLS 1.0 betroffen gewesen hätten wir nun ein riesiges Problem, denn das wird von ca. 40% der Verbindungen genutzt.

Ein weiteres Problem, das diese Attacke gefährlich macht ist die Downgrade-Möglichkeit von TLS/SSL. Obwohl ein Client (Browser) TLS >1.0 beherrscht, kann ein Angreifer dafür sorgen dass sich die beiden Kommunikationspartner auf SSLv3 einigen indem der Angreifer die Netzwerkverbindung passend trennt. Dadurch sind plötzlich alle betroffen! Selbst wenn beide TLS >=1.0 beherrschen, aber auch SSLv3 noch aktiviert haben, kann ein Angreifer dafür sorgen dass sich beide für das schlechteste Protokoll entscheiden. Gegen diese Downgrade-Attacken wird es bald in OpenSSL Gegenmaßnahmen geben, die sich noch in der Standardisierung befinden: TLS Fallback SCSV

Die Lösung: Sowohl clientseitig als auch serverseitig SSLv3 deaktivieren. Chrome und Firefox werden das in den nächsten Wochen im Browser tun. Viele Webseiten- und Dienstebetreiber haben die Lücke nun zum Anlass genommen und SSLv3 auch serverseitig deaktiviert.

Hier eine Liste von E-Mail-Providern und den Ergebnissen, ob sie noch SSLv3 anbieten (Stand: 16.10.2014 11:30, also ca. 36 Stunden nach der Veröffentlichung):

AnbieterWebserver SSLv3 deaktiviert?Qualys SSL-TestergebnisMX-Server SSLv3 deaktiviert?IMAP-Server SSLv3 deaktiviert?SMTP-Server SSLv3 deaktiviert?
mail.dejaA+jajaja
posteo.dejaA+neinneinnein
mailbox.orgjaAneinneinnein
iCloudjaBneinjanein
FreenetjaBneinneinnein
T-OnlineneinA+neinneinnein
GMailneinAneinneinnein
StratoneinAneinneinnein
web.deneinAneinneinnein
GMXneinAneinneinnein
YahooneinAneinneinnein
ArcorneinA-neinneinnein
ok.deneinBneinneinnein

Einige deutsche Anbieter sind sicher und haben SSLv3 deaktiviert. Doch viele haben noch nicht reagiert und sind angreifbar/abhörbar.

Testen kann man es selbst mit folgendem Befehl unter Linux:

openssl s_client -ssl3 -connect mail.yahoo.com:443
openssl s_client -crlf -ssl3 -connect imap.yahoo.com:993
openssl s_client -starttls smtp -crlf -ssl3 -connect mta5.am0.yahoodns.net:25

Dort natürlich den passenden Hostnamen einsetzen. Wenn eine Fehlermeldung kommt und keine Verbindung zustande kommt ist SSLv3 abgeschaltet. Kommt eine Verbindung zustande und wird „Protocol: SSLv3“ gemeldet ist die Seite angreifbar.

Oder aber auf der Testwebseite von Qualys.

Im Anhang befinden sich meine Testergebnisse.

posteo.de.443 mailbox.org.443 mail.google.com.443 mail.de.443 web.de.443 gmx.net.443 email.t-online.de.443 email.freenet.de.443 arcor.de.443 ok.de.443 mail.yahoo.com.443 www.icloud.com.443 communicator.strato.com.443 mx01.mail.de.25 mx02.posteo.de.25 mx01.mailbox.org.25 mx1.mail.icloud.com.25 mx01.t-online.de.25 gmail-smtp-in.l.google.com.25 smtp.rzone.de.25 mx-ha02.web.de.25 mx01.emig.gmx.net.25 mta5.am0.yahoodns.net.25 mx.arcor.de.25 front0.ok.de.25 emig.freenet.de.25 imap.mail.de.993 imap.posteo.de.993 imap.mailbox.org.993 imap.mail.me.com.993 secureimap.t-online.de.993 imap.gmail.com.993 imap.strato.de.993 imap.web.de.993 imap.gmx.net.993 imap.mail.yahoo.com.993 imap.arcor.de.993 imap.ok.de.993 imap.freenet.de.993 smtp.mail.de.587 smtp.posteo.de.587 smtp.mailbox.org.587 smtp.mail.me.com.587 securesmtp.t-online.de.587 smtp.gmail.com.587 smtp.strato.de.587 smtp.web.de.587 smtp.gmx.net.587 smtp.mail.yahoo.com.587 mail.arcor.de.587 smtp.ok.de.587 mx.freenet.de.587

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:
(Update 16.10.2014: mailbox.org hinzugefügt)

AnbieterDNSSECDANEProtokolleBesonderheiten
mail.de++MX, HTTPS, SMTP, IMAP, POP3, CalDAV, CardDAV, WebDAV, JabberAuch alle Alias-Domains sind gesichert
mailbox.org++MX, HTTPS, SMTP, IMAP, POP3- (keine Aliasdomains zur Auswahl, nur externe Kundendomains, und die sind natürlich nicht 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:
preload preload preload