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