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 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:
Jan 20

Perfect Forward Secrecy (PFS) ist in aller Munde seit den Enthüllungen durch Edward Snowden. Wir wissen nun definitiv dass die NSA alle Daten mitschneidet die sie in die Finger kriegt, um sie eventuell in einigen Jahren, wenn die Computer schnell genug sind oder Quantencomputer verfügbar sind, komplett zu entschlüsseln, die ganze Vergangenheit der letzten X Jahre.

Damit genau das nicht möglich ist gibt es Verschlüsselungsstandards (Ciphers) die das komplette nachträgliche Entschlüsseln mit nur einem Schlüssel unmöglich machen. Jede einzelne Verbindung muss dann geknackt werden, was natürlich millionenfach mehr Arbeit bedeutet. Doch welcher E-Mail-Anbieter bietet solche Verschlüsselungen mit Perfect Forward Secrecy?

Ich habe ein kleines Testscript geschrieben und es bei 14 E-Mail-Anbietern laufen lassen. Alle Ciphers die mit DH (Diffie-Hellman-Schlüsselaustausch) oder ECDH (Elliptic Curve Diffie-Hellman) beginnen sind PFS-fähig.

AnbieterIMAP DienstPOP3 DienstSMTP Dienst
mail.deECDHE-RSA-RC4-SHAECDHE-RSA-RC4-SHAECDHE-RSA-AES256-SHA
GoogleMailECDHE-RSA-RC4-SHAECDHE-RSA-RC4-SHAECDHE-RSA-RC4-SHA
freenet.deDHE-RSA-AES256-SHADHE-RSA-AES256-SHADHE-RSA-AES256-SHA
AOLDHE-RSA-AES256-SHADHE-RSA-AES256-SHADHE-RSA-AES256-SHA
ok.deDHE-RSA-AES256-SHADHE-RSA-AES256-SHADHE-RSA-AES256-SHA
ArcorAES256-SHAAES256-SHADHE-RSA-AES256-SHA
GMXAES256-SHAAES256-SHAECDHE-RSA-AES256-SHA
web.deAES256-SHAAES256-SHAECDHE-RSA-AES256-SHA
T-OnlineAES256-SHADES-CBC3-SHADES-CBC3-SHA
1und1AES256-SHAAES256-SHAAES256-SHA
emailn.deAES256-SHAAES256-SHAAES256-SHA
outlook.comAES128-SHARC4-MD5RC4-MD5
iCloudRC4-MD5-- kein POP3 Support --RC4-MD5
YahooRC4-SHARC4-SHARC4-SHA

Ich habe die PFS-fähigen Dienste grün markiert und nach Anzahl sortiert. Die elliptischen Kurven sind dabei neuer und noch etwas sicherer, deshalb stehen sie ganz oben.

Nur ein Drittel kann sich als sicher bezeichnen. Besonders enttäuschend sind natürlich die großen deutschen Anbieter GMX, web.de und T-Online, die mehr als 75% des deutschen Marktes abdecken. Wie auch bereits in anderen Sicherheitstests hier im Blog zu sehen kümmern sie sich nicht sonderlich engagiert um maximale Sicherheit.

Technisches Detail: Ich habe die SSL-Ports untersucht wo dies möglich ist. Nur wenn dies nicht möglich war habe ich die STARTTLS-Verbindungen untersucht.

Tagged with:
Jun 25

Vor wenigen Tagen hat der Whistleblower Edward Snowden der Öffentlichkeit bekannt gemacht dass Geheimdienste unsere Kommunikation im großen Stil belauschen. Im Falle der USA (Projektname Prism) werden sowohl gespeicherte Daten als auch Live-Kommunikation direkt bei den Anbietern abgefragt. Angeblich soll die NSA direkten Zugriff auf die Server von Google, Apple, Yahoo, Microsoft usw. haben.

Der britische Geheimdienst GCHQ (Projektname Tempora) zapft transatlantische Glasfaserkabel an, sodass ein Großteil der britischen Kommunikation abgehorcht wird. Da aber nicht nur britische Daten sondern auch die Daten aller europäischen Länder zum großen Teil über Großbritannien nach Amerika gelangen, sind „wir“ auch betroffen von der großen Lauschaktion. Es gibt auch Abhöreinrichtungen hier in Deutschland, beispielsweise beim größten deutschen Internetknoten DECIX.

Wie werden E-Mails übertragen?

Eine E-Mail von Person A nach Person B muss in den meisten Fällen 3 Wege nehmen:

  1. Vom Absender A zum eigenen E-Mail-Anbieter, häufig via Webmail oder externem Client (Outlook, Thunderbird…) unter Zuhilfenahme des SMTP-Protokolls. Bei dieser Einlieferung bieten eigentlich alle Anbieter eine Verschlüsselung an, entweder wird das ältere Verfahren SMTP-SSL angeboten (Port 465) oder das modernere STARTTLS über Port 25 oder 587. Falls der Webmailer benutzt wird unterstützen fast alle HTTPS. Hierbei kann die E-Mail also verschlüsselt übertragen werden, ein „Mitlauschen auf dem Kabel“ ist nicht möglich.
  2. Der Anbieter des Absenders kümmert sich nun darum die E-Mail an den Anbieter des Empfängers B zu senden. Dazu schaut er im DNS-System nach welcher Mailserver zuständig ist, verbindet sich mit diesem und sendet die E-Mail an den Server des Empfängers. Dabei können diese beiden Server auch verschlüsselt kommunizieren wenn es beide unterstützen. Falls einer von beiden es nicht beherrscht, wird die E-Mail im Klartext übertragen und kann problemlos mitgeschnitten werden.
  3. Wenn die E-Mail im Postfach des Empfängers B liegt kann der Empfänger sie mittels Webmail, IMAP oder POP3 abholen. Hierbei bieten auch wiederum die meisten Anbieter eine Verschlüsselung an, sei es HTTPS im Falle des Webmailers oder SSL bzw. TLS im Falle von IMAP und POP3.

Bei den Schritten 1 und 3 bieten wie bereits geschrieben die meisten Anbieter eine Verschlüsselung an, wenn der Benutzer es aktiviert und nutzt ist die Kommunikation abhörsicher. Problematisch ist Schritt 2, denn darüber haben weder der Sender A noch der Empänger B die Kontrolle. Häufig wird dieser Schritt auch vergessen, man denkt man verbinde sich verschlüsselt via IMAP und meint dann, die E-Mail sei nach wie vor geheim.

Verschlüsselung bei den Anbietern

Um herauszufinden welcher Anbieter bei der sogenannten Server-to-Server (Schritt 2) Verbindung eine Verschlüsselung anbietet habe ich einige Tests gemacht. Dazu habe ich mit Hilfe des Dienstes CheckTLS die wichtigsten E-Mail-Anbieter untersucht, und zwar ob die Eingangsserver STARTTLS anbieten:

AnbieterTLS AdvertisementCertificate OKTLS Negotiation
FreenetOKOKOK
mail.deOKOKOK
ArcorOKOKOK
GooglemailOKOKFAIL
emailn.deOKOKFAIL
1und1OKOKFAIL
kabelmailOKOKFAIL
YahooFAILFAILFAIL
AOLFAILFAILFAIL
web.deFAILFAILFAIL
GMXFAILFAILFAIL
Hotmail/Outlook.comFAILFAILFAIL
FacebookMailFAILFAILFAIL
Apple me.com/icloud.comFAILFAILFAIL
StratoFAILFAILFAIL

Alle Anbieter, die ein FAIL zu verzeichnen haben bieten keine sichere Server-to-Server Verschlüsselung an. Sendet also beispielsweise jemand eine E-Mail von Freenet an GMX, dann wird diese E-Mail im Klartext verschickt, denn die Eingangsserver von GMX beherrschen keine Verschlüsselung. Die Details des Tests inklusive der Screenshots der Ergebnisse befinden sich unter diesem Artikel.

Um zu überprüfen ob ein Anbieter bei den Ausgangsservern STARTTLS unterstützt müßte man vom jeweiligen Anbieter eine E-Mail versenden an einen TLS-fähigen Empfängerserver, und dann nachschauen ob TLS genutzt wurde oder nicht. Da ich nur bei einigen Anbietern einen Account habe lasse ich diese Frage erstmal offen.

Fazit

Wie man sieht ist es kein erfreuliches Ergebnis. Bis auf Freenet, mail.de, und Arcor bietet keiner der großen eine einwandfreie sichere Kommunikation zwischen den Servern, ein Mitlauschen ist demnach sehr einfach möglich indem sich, wie gerade veröffentlicht, Geheimdienste an die Knotenpunkte im Internet hängen und einfach mitlesen. Sobald einer der beiden beteiligten Server es nicht unterstützt, wird im Klartext übertragen, was bei einem sehr hohen Prozentsatz der Fall sein wird, denn wenn nur ein Drittel die Verschlüsselung unterstützt müßten die Chancen ungefähr bei 1/9 stehen dass die E-Mails verschlüsselt übertragen werden.

Bei der Auswahl eines Anbieters sollte man also neben der noch freien Wunsch-E-Mail-Adresse auch auf die technische Expertise, den Support und die Sicherheit achten.

Tagged with:
preload preload preload