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 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:
Mrz 21

Microsoft durchsucht die E-Mail-Postfächer seiner Nutzer, und zwar nicht automatisch durch Algorithmen sondern auch manuell durch Personen, ohne dass die davon etwas wissen oder gar gefragt werden.

Microsoft kritisierte Google sehr scharf in der Vergangenheit dafür dass sie die E-Mails der GMail-Nutzer scannen würden um personalisierte Werbung anzeigen zu können. Mit der Scroogled Kampagne hetzt Microsoft gegen Google, dass dort der Datenschutz der Nutzer nicht beachtet werde, und man deshalb von Google weggehen und Microsoft Dienste und Hardware nutzen solle. Das hat aber einen besonders faden Beigeschmack wenn Microsoft selbst auch die E-Mails und Daten der eigenen Benutzer scannt und durchsucht.

Nun ist herausgekommen dass Microsoft auf der Suche nach einem internen Geheimnisverräter auch das E-Mail-Konto eines Hotmail-Nutzers durchsucht hat, und zwar nicht mit automatisierten Algorithmen sondern persönlich durch Mitarbeiter. Als Rechtfertigung ließ Microsoft verlauten: „Wie dürfen das laut AGB“. Na toll, erst den großen Moralapostel spielen und dann selbst die Daten der eigenen Nutzer durchsuchen.

Hotmail bzw. outlook.com ist auch einer der wenigen E-Mail-Anbieter die noch keine STARTTLS-Transportverschlüsselung anbieten, eigentlich ein Ding der Unmöglichkeit im Jahre 2014, nach den Snowden-Enthüllungen. Aber aus irgendeinem Grund scheint sich Microsoft gegen diesen Schutz zu entscheiden. Man kann nur jedem raten von Microsofts E-Mail-Diensten die Finger zu lassen.

Der Trend geht also weiter Richtung deutsche Anbieter, die dem deutschen Datenschutzgesetz folgen müssen und sich an strengere Regeln halten müssen, denn in Amerika gibt es kein Bundesdatenschutzgesetz oder ähnliches. Durch Vorfälle wie diese entscheiden sich immer mehr Deutsche für einen Umzug zu einem deutschen E-Mail-Anbieter.

Tagged with:
Nov 12

Aus aktuellem Anlass wurden einige Anbieter geprüft, wie diese mit der IP-Adresse des Versenders verfahren. Werden diese anonymisiert oder in Klarform in den erweiterten Headerinformationen gespeichert?

Wer gelegentlich E-Mails an Mailinglisten schreibt oder an Personen, die nicht unbedingt wissen sollen aus welcher Stadt/Gegend man kommt, für den ist es nicht uninteressant, wie die großen E-Mail-Provider mit der IP-Adresse des Computers umgehen von der die E-Mails versendet werden.

Verräterisch können dabei die E-Mail-Header (deutsch: Kopfzeilen) sein, in denen viele E-Mail-Anbieter die IP-Adresse vermerken, anhand der Empfänger sehen, aus welcher Gegend/ Stadt die E-Mail geschrieben wurde. Eventuell können noch weitere Schlüsse aus diesem Header gezogen werden. Beispielsweise schreiben einige Anbieter sogar die interne Netzwerkadresse oder den Computernamen in die Header !

MailHops BeispielEs geht um die sogenannten „Received-Header“, die in einer E-Mail anzeigen von welchem Ort und wohin diese transportiert wurde. Und zu diesem Transportweg gehört bei einigen Anbietern auch der einliefernde Computer, der die E-Mail verfasst und abschickt. Aus Datenschutzgründen möchte man natürlich nicht, dass die Empfänger wissen, von welchem Ort die E-Mail versendet wurde, mit welchem Gerät die E-Mail geschrieben wurde und wie das interne Netzwerk aussieht.

Gerade im geschäftlichen E-Mail-Verkehr kann eine nicht vorhandene Anonymisierung der IP-Adresse zu Unannehmlichkeiten führen. Ein Beispiel:

  1. Der Firmensitz der eigenen Firma ist in Deutschland. Die Geschäftskontakte (Lieferanten, Kunden etc.) sind ebenfalls alle in Deutschland ansässig. Die Geschäfte lassen sich aufgrund des Internetzeitalters von der ganzen Welt aus steuern, so daß man eine zeitlang seine Geschäfte aus dem Ausland, zum Beispiel vom Zweitwohnsitz aus regeln möchte. Dieses sollten Geschäftspartner und Kunden nicht wissen, so daß die Nutzung eines E-Mail Providers von Vorteil wäre, der die sensiblen Daten, wie IP-Adresse und  den Computernamen etc. nicht in den Received-Headern abspeichert. Nutzt man den falschen E-Mail Provider kann im Zweifel der Standort des Senders vom Empfänger herausgefunden werden. Lieferanten könnten aufgrund der ausländischen IP/des vermeintlich ausländischen Firmensitzes  misstrauisch werden, Bürgschaften aus Sicherheitsgründen verlangen oder im schlimmsten Fall den Liefervertrag aus Vorsicht kündigen…

Anbei die Übersicht, getrennt nach Anbietern und jeweils der Angabe beim Versand über den Webmaildienst oder einem externes Programm (wie z.B. Thunderbird, Apple Mail oder Outlook):

Versand per SMTPVersand per Webmailer
mail.dekeine IP enthaltenkeine IP enthalten
GMailinterne IP und öffentliche IPkeine IP enthalten
outlook.cominterne IP und öffentliche IPkeine IP enthalten
web.deinterne IP und öffentliche IPöffentliche IP
GMXinterne IP und öffentliche IPöffentliche IP
Yahoointerne IP und öffentliche IPöffentliche IP
Freenetinterne IP und öffentliche IPöffentliche IP
T-Onlineinterne IP und öffentliche IPöffentliche IP
Arcorinterne IP und öffentliche IPöffentliche IP

Alle Anbieter, bis auf den recht jungen und neuen E-Mail Provider „mail.de“, verraten die Absende-IP-Adresse, wenn eine E-Mail mit einem E-Mail-Client versendet wird, ebenso wie sogar der Computername bzw. die interne IP-Adresse des Computers festgehalten. Es hängt vom E-Mail-Client ab, ob die interne IP-Adresse oder gar der Computernamen (Bernd-PC) auftaucht.

Man sollte sich sicher sein, dass der eigene Anbieter nicht diese sensiblen Daten mit in die E-Mails schreibt, die man verschickt. Zu empfehlen ist also aktuell nur „mail.de“. Oder man nutzt Anonymisierungsdienste wie „Tor“ oder „VPN-Dienste“, was für viele Anwender aber zu kompliziert bzw. zu teuer ist.

Zum besseren nachvollziehen wurden die Textdateien mit Headerbeispielen angehängt. Am besten ist es jedoch selbst auszuprobieren, wie der eigenen E-Mail Provider verfährt: Einfach eine E-Mail versenden und beim Empfänger in die Kopfzeilen schauen! Hilfreich ist auch das bereits hier vorgestellte Thunderbird-Addon MailHops, das grafisch den Weg einer E-Mail anzeigt.

mail.de Arcor gmail GMX outlook.com T-Online web.de Yahoo Freenet

 

Tagged with:
preload preload preload