zurück zum Artikel

Ungesicherte Einsichten

| Christiane Rütten

Nur Smartphone-Apps mit ordentlicher Verschlüsselung bieten Schutz vor unerwünschten Mitlauschern. Wir haben den beliebtesten Anwendungen für Android und iPhone auf den Zahn gefühlt.

Ungesicherte Einsichten

Im Smartphone-Zeitalter müssen Angreifer nicht mehr in gut gesicherte Netzwerke einbrechen, um wichtige Daten abzuhören. Nun sind es die Nutzer, die ihre Mobiltelefone in fremde Netze tragen. Umso wichtiger ist es, dass die Apps eine ordentliche Verschlüsselung bieten. Wir haben den beliebtesten Anwendungen für Android und iPhone auf den Zahn gefühlt.

Kontakte, E-Mails, Kurznachrichten und Zugangsdaten zu Banking- und Online-Shopping-Portalen machen die Datenübertragungen von Smartphones zu einem attraktiven Angriffsziel. In einem offenen WLAN genügt ein simpler Netzwerksniffer wie tcpdump oder Wireshark, um beispielsweise unverschlüsselte Passwörter unbemerkt abzufischen. Verschlüsselte WLANs bieten zwar einen gewissen Schutz gegen passives Mitlauschen, trotzdem kann ein Netzwerkteilnehmer einen Man-in-the-Middle-Angriff (MITM) durchführen und die Verbindung anderer WLAN-Clients über den eigenen Rechner umleiten.

Die Hauptschwachstelle ist zwar derzeit das WLAN, doch es wäre kurzsichtig, sich mit GSM, UMTS oder HSDPA in Sicherheit zu wiegen. IMSI-Catcher waren lange Zeit Strafverfolgungsbehörden vorbehalten, doch jüngste Fortschritte in der Entwicklung hausgemachter Basisstationen machen deutlich, dass künftig jedermann für kleines Geld den Mobilfunkdatenverkehr über eine Schnüffelstelle umleiten kann.

Vor solchen Tricks schützt nur eine Verbindungsverschlüsselung, für die üblicherweise das Protokoll Secure Socket Layer (SSL) beziehungsweise die neuere Version namens Transport Layer Security (TLS) – nachfolgend einfach SSL genannt – verwendet wird. Für eine SSL-Verbindung schickt der Server dem Client ein Zertifikat, das von einer anerkannten Zertifizierungsstelle digital signiert wurde. Anhand einer Liste von vertrauenswürdigen Herausgeberzertifikaten kann eine App sicherstellen, mit dem richtigen Server zu sprechen und nicht mit einem Mittelsmann. Derart geschützte Daten lassen sich nicht passiv mitlesen und auch ein MITM-Angriff fällt durch ein ungültiges Zertifikat auf. Allerdings ist es die Aufgabe der App beziehungsweise des Smartphone-Betriebssystems, die Zertifikate zu prüfen, was in unseren Tests nicht immer funktionierte.

In der Regel gilt für Smartphone-Apps das Black-Box-Prinzip: Ob sie die übertragenen Daten zuverlässig vor ungebetenen Lauschern schützen, ist für Laien gar nicht und selbst für Profis nur mit erheblichem Aufwand erkennbar. Wir haben daher eine repräsentative Auswahl von beliebten Android- und iPhone-Anwendungen unter die Krypto-Lupe genommen und sie mit gängigen Angriffstechniken malträtiert.

Selbst in verschlüsselten WLANs kann ein Angreifer unter Umständen mit ARP-Vergiftung die Datenpakete zwischen Mobiltelefon und Router über sich umleiten. Schlampt eine Mobil-App bei der Zertifikatsprüfung, kann er sogar SSL-Verbindungen abfangen.

Selbst in verschlüsselten WLANs kann ein Angreifer unter Umständen mit ARP-Vergiftung die Datenpakete zwischen Mobiltelefon und Router über sich umleiten. Schlampt eine Mobil-App bei der Zertifikatsprüfung, kann er sogar SSL-Verbindungen abfangen.

Zum Test der insgesamt 20 Android- und 15 iPhone-Apps und -Systemkomponenten haben wir ein Setup aus gängigen, frei verfügbaren Angriffs- und Analysetools aufgebaut. Zwischen einen WLAN-Router mit WPA2-Verschlüsselung und seine Internetverbindung haben wir einen Rechner mit zwei Netzwerkkarten geschleift, auf dem die auf Sicherheits-Audits ausgelegte Linux-Distribution BackTrack 4 lief. Auf dem BackTrack-System setzten wir das Schnüffeltool ettercap ein, das diverse Protokolle wie HTTP, IMAP und SMTP interpretieren und gezielt nach Zugangsdaten durchsuchen kann. Auf einem Notebook im WLAN des Routers war ettercap auch in der Lage, den Netzwerkverkehr der beiden Smartphones per ARP-Poisoning und DHCP-Spoofing über sich umzuleiten.

Etwas trickreicher mussten wir beim Knacken der SSL-Verbindung vorgehen. Dafür verwendeten wir sslsniff, das sich mit gefälschten Zertifikaten in durchgehende Verbindungen einschleift, indem es eine eigene SSL-Verbindung zum Server aufbaut und dem Client ein gefälschtes Zertifikat schickt (siehe Bild). Dieser Angriff ist nur erfolgreich, wenn Clients (oder deren Nutzer) bei der Zertifikatsprüfung versagen.

Die Auswahl der Testkandidaten erfolgte anhand der vier Kategorien Systemdienste, E-Mail und Instant-Messenger, Soziale Netzwerke sowie Banking und Shopping. Hinzu kamen die wichtigsten Betriebssystemdienste wie Browser, Google Market und der AppStore. Auch den Dateisynchronisationsdienst Dropbox und das Web-basierte Notizbuch Evernote haben wir mitgetestet, da sie weit verbreitet sind. Die Tests erfolgten unter dem immer noch am weitesten verbreiteten Android 2.1 sowie unter iOS 4.0.3.

Oops, sslsniff hat ein Twitter-Passwort erwischt. Der Android-Client Twidroyd hat vergessen, das SSL-Zertifikat zu prüfen ...

Oops, sslsniff hat ein Twitter-Passwort erwischt. Der Android-Client Twidroyd hat vergessen, das SSL-Zertifikat zu prüfen ...

Die Anwendungen lassen sich in drei Verschlüsselungskategorien einteilen. Ein Teil der Mobil-Apps verschlüsselt den kompletten Datenverkehr zu ihren Servern im Internet. Das ist unverzichtbar, wenn wie etwa bei einer Banking-Anwendung oder einem E-Mail-Programm ausschließlich schützenswerte Daten über die Leitung gehen.

... und ohne Murren unser gefälschtes akzeptiert.

... und ohne Murren unser gefälschtes akzeptiert.

Um den Rechenbedarf für Clients und Server kleinzuhalten, verschlüsseln andere Apps lediglich das Login und versenden die restlichen Anwendungsdaten im Klartext. So schlüpfen vielleicht doch mal schützenswerte Daten über die unverschlüsselte Verbindung – etwa die Notizbuchinhalte von Evernote. Außerdem kann ein Angreifer in der Regel den Inhalt der umgeleiteten Klartextpakete manipulieren und unter Umständen ist es sogar möglich, Sitzungsdaten für unautorisierte Zweitverbindungen zu missbrauchen.

Das dritte Konzept ist der völlige Verzicht auf Verschlüsselung – selbst für Logins. Dieses Verhalten mussten wir bei drei Android-Apps feststellen. Unverschlüsselte Logins enthüllen nicht unbedingt Nutzername und Passwort, weil sie sich beispielsweise mit Hash-Funktionen verschleiern lassen, aber unter Umständen sind Replay-Angriffe möglich, indem man die abgefangenen Logins noch einmal von einem anderen Gerät aus verschickt. Ob derartige Angriffe erfolgreich sind, hängt allerdings vom jeweiligen Dienst ab und erfordert eine tiefgehende Einzelfallanalyse, die über den Rahmen des Artikels hinausgeht.

Ein Android-Gerät ist aus dem Netzwerk nicht von außen erreichbar, weil es standardmäßig keine Ports geöffnet hat – weder TCP noch UDP. Zu den wichtigen Systemdiensten zählen der Chrome-Browser, Google Market sowie Google Sync, das etwa für den automatisierten Abgleich von Telefonbuch und Kalenderdaten mit dem Nutzerkonto auf den Google-Servern sorgt. Die Google-Dienste sind durchweg nicht für SSL-MITM-Angriffe anfällig, da sie die Zertifikate ordentlich prüfen.

Vorsicht, Angriff! Die Palette der Warnungen bei gefälschten Zertifikaten reicht von kaputt (Twitter-App für iPhone) über ...

Vorsicht, Angriff! Die Palette der Warnungen bei gefälschten Zertifikaten reicht von kaputt (Twitter-App für iPhone) über ...

Der Android Market überträgt unwesentliche Daten wie Suchbegriffe und App-Downloads im Klartext. Keine Sorge: Die Apps sind durch eine digitale Signatur vor Manipulation geschützt. Die Steuerverbindung über eine Google-Talk-Verbindung auf Port 5228, über die die App beispielsweise Downloads und Zahlungen autorisiert, ist verschlüsselt.

... unspezifisch (AppStore) ...

... unspezifisch (AppStore) ...

Google Sync verschlüsselt die meisten Daten sicher, schickt aber gelegentlich bei Synchronisationsvorgängen Serveranfragen mit dem Namen des mit dem Smartphone verknüpften Google-Kontos im Klartext. Je nachdem, was man über die Google-Adresse über den Inhaber erfahren kann, ist das durchaus problematisch. Der Chrome-Browser verschlüsselt je nach Website sicher und lässt sich auch nicht mit gefälschten Zertifikaten hinters Licht führen. Eine aktive Verschlüsselung erkennt man an dem Schlosssymbol in der Adressleiste. Anders als bei Safari auf dem iPhone lassen sich über Chrome Herausgeberzertifikate nicht systemweit nachrüsten, sondern nur für den Browser. Eine systemweite Installation wäre aber durchaus wünschenswert.

... bis hin zu falsch (PayPal).

... bis hin zu falsch (PayPal).

Die auf den AOL-IM-Dienst spezialisierte App AIM nimmt es mit der Datensicherheit nicht so genau und verschlüsselt bis auf den optionalen Facebook-Login gar nichts. Immerhin wandert das AIM-Passwort nicht im Klartext über die Verbindung, sondern vermutlich mit einer Hash-Funktion verschleiert. Bei Google Mail und Google Talk gibt es nichts zu meckern. Beide Anwendungen verschlüsseln ordentlich und fallen auch nicht auf MITM-Angriffe herein.

Der Multi-Instant-Messenger Meebo folgt einem ungewöhnlichen Designprinzip: Man speichert die Zugangsdaten für die IM-Dienste auf den Meebo-Servern, die sich um die Verbindung kümmern, und der Client ist nur ein Frontend für den Webdienst. Wer Meebo seine Passwörter anvertrauen mag, bekommt einen sicheren Messenger, der komplett verschlüsselt ist und über nahezu jede Internetverbindung funktioniert.

Äußerst vertrackt ist die Situation unter Android bei E-Mail-Apps. Deren Sicherheit steht und fällt mit der korrekten Einrichtung der Clients. Sowohl die im Stock-Rom mitgelieferte App namens E-Mail und der Client namens Mail, den HTC seiner Sense-Oberfläche beilegt, als auch die weit verbreitete Alternative K-9 Mail sind unsicher und Angriffen schutzlos ausgeliefert, wenn man einfach nur die Voreinstellungen abnickt. Wie man die Programme abhörsicher einrichtet, erklärt der Kasten auf der letzten Seite [1] dieses Artikels.

Sozialnetzwerker sollten die Facebook-App nicht über öffentliche WLANs benutzen, sofern sie die Namen ihrer Kontakte und Nachrichteninhalte lieber für sich behalten möchten. Ebenfalls große Vorsicht ist bei der auf einigen Geräten mit Android 2.1 vorinstallierten Twitter-App geboten. Sie verschlüsselt nämlich gar nicht – nicht einmal den Login. Das gibt es erst ab einer der Folgeversionen, etwa der bei Android 2.2 mitgelieferten. Den weitaus größten Patzer leistet sich der Client Twidroyd, der zwar alles verschlüsselt, letztlich aber die Zertifikatsüberprüfung vergisst. Mit einem MITM-Angriff lassen sich ihm Nutzername, Passwort und sämtliche Nachrichten entlocken, ohne dass der Nutzer davon etwas mitbekommt. Wer auch in nicht vertrauenswürdigen Netzen twittern möchte, greift daher besser zu dem fehlerlos verschlüsselnden Seesmic. Der Android-App für das Karrierenetzwerk Xing ließen sich nur vergleichsweise unwichtige Daten wie Bilder entlocken, weil sie bei ihnen auf Verschlüsselung verzichtet.

Im Bereich Banking und Shopping geht es um Geld, sodass die Toleranzschwelle für unverschlüsselte Daten sehr niedrig liegt. Pocket Auctions für eBay geht mit schlechtem Beispiel voran und verschlüsselt gar nicht. Lediglich das Passwort wird nicht im Klartext übertragen. Die PayPal-App macht bei normalen Bezahlvorgängen alles richtig und verschlüsselt die Kommunikation mit den PayPal-Servern sauber. Sobald man jedoch das Bump-Feature verwendet, mit dem man zwei Telefone durch Zusammenstupsen für Transaktionen verbindet, überträgt die App den PayPal-Nutzernamen unverschlüsselt zum Bump-Server. Es handelt sich lediglich um eine E-Mail-Adresse, aber bei PayPal übernimmt sie die Funktion der Kontonummer. Nichts auszusetzen gab es hingegen an S-Banking von Star Finanz. Die nicht auf Sparkassen beschränkte Banking-App ließ sich nicht in die Karten schauen.

Zwei weit verbreitete In-The-Cloud-Anwendungen, die ebenfalls ein lohnendes Angriffsziel darstellen dürften, sind das Online-Notizbuch Evernote und das Dateisynchronisierungstool Dropbox. Beide machen zwar einen sicheren Login, aber ausgerechnet Notizen und Dateinamen übertragen sie unverschlüsselt. Wir konnten sogar den Inhalt einiger von Dropbox übertragenen Dateien mitlesen. Diese Patzer leisten sich die Apps auch auf dem iPhone.

iPhones sind über TCP-Port 62078 für iPhone-Sync und UDP-Port 5353 für Zeroconf/Bonjour aus dem Netzwerk erreichbar. Eine Sicherheitslücke in einem der Dienste kann unter Umständen fatale Auswirkungen für die iPhone-Nutzerschaft haben, aber wer regelmäßig die Firmware-Updates einspielt, sollte auf der sicheren Seite sein. Alle getesteten iPhone-Apps verschlüsseln ihre Logins ordentlich. Passwörter konnten wir per MITM-Angriff lediglich von einem offensichtlich unsicher konfigurierten E-Mail-Zugang abgreifen. Die App-Spreu vom App-Weizen trennte sich lediglich bei der Verschlüsselung der Nutzdaten.

Im Angriffsfall mit einem gefälschten Zertifikat lässt Apples Browser Safari keine Verbindung zu.

Im Angriffsfall mit einem gefälschten Zertifikat lässt Apples Browser Safari keine Verbindung zu.

Von den iOS-Systemdiensten verschickte nur iBooks, über das intern auch der AppStore abgewickelt wird, einen Teil der Daten im Klartext – aber nichts Bedenkliches. Der iPhone-Push-Dienst, den eine Reihe von Anwendungen für asynchrone Nutzerbenachrichtigungen nutzen, verschlüsselte stets komplett.

Der Browser Safari bietet Nutzern die Möglichkeit, Herausgeberzertifikate systemweit zu installieren. Klickt man auf einer Webseite auf eine korrekt ausgezeichnete Zertifikatsdatei, öffnet sich ein Dialog für den Import, der gegebenenfalls nach der Geräte-PIN verlangt. Nach dem Import tauchen die neuen Zertifikate unter Einstellungen / Allgemein / Profile auf. Derart eingerichtete Herausgeberzertifikate gelten fortan auch für die meisten anderen Programme, etwa die E-Mail-App, als vertrauenswürdig.

Google Chrome liefert Zertifikats-informationen und bietet leichtsinnigen Naturen die gefährliche Option „Fortfahren“ an, die Angreifer mitlauschen lässt.

Google Chrome liefert Zertifikats-informationen und bietet leichtsinnigen Naturen die gefährliche Option „Fortfahren“ an, die Angreifer mitlauschen lässt.

Der einzige Mailer für das iPhone ist MobileMail. Er liefert ein gutes Beispiel für durchdachte Nutzerführung, denn wenn die verwendeten Mail-Server ordentliche Verschlüsselung bieten, ist es kaum möglich, das Konto unsicher einzurichten. Beim Anlegen eines neuen Kontos hat der Anwender gar nicht erst die Wahl, eine unverschlüsselte Verbindung zu verwenden. MobileMail versucht es immer zuerst mit SSL / TLS, und nur wenn das fehlschlägt, bietet es dem Nutzer nach einer Warnung die unverschlüsselte Übertragung an. Eine Möglichkeit, die wichtigen Zertifikatschecks zu umgehen, ist sinnvollerweise gar nicht erst vorgesehen. Selbstsignierte Zertifikate muss man vor der Kontoeinrichtung etwa über Safari installieren.

Für Instant-Messaging bietet sich auf dem iPhone der Client für den Web-Dienst Meebo an, der diverse Protokolle unterstützt. Wie unter Android wandern alle wichtigen Daten über eine verschlüsselte Verbindung zu den Meebo-Servern, die für die Logins die Passwörter speichern müssen. Allerdings konnten wir bei Meebo für iOS auch unverschlüsselte Daten beobachten – immerhin nur unwichtige.

Die offizielle Facebook-App überträgt ihre Daten im Klartext – ärgerlich, wenn man anderen WLAN-Benutzern damit sein soziales Netzwerk und seine Nachrichten offenlegt. Die Anwendung für Xing ist da etwas vorsichtiger. Bei ihr konnten wir lediglich vergleichsweise unwichtige Bilddaten im Klartext abfangen.

Das iPhone bietet über die Profileinstellungen ein zentrales Zertifikatsmanagement. Herausgeberzertifikate lassen sich etwa über Safari nachrüsten.

Das iPhone bietet über die Profileinstellungen ein zentrales Zertifikatsmanagement. Herausgeberzertifikate lassen sich etwa über Safari nachrüsten.

Der offizielle Twitter-Client ist durchweg sicher und kommuniziert ausschließlich verschlüsselt mit den Servern des Mikroblogging-Dienstes. Bei Echofon hingegen ist die Datenverschlüsselung optional und per Default ausgestellt. Die Option befindet sich unter Menu / Settings / Use SSL. Der Settings-Knopf ist leicht zu übersehen links unten im Menü platziert.

Im Banking- und Shopping-Bereich haben wir S-Banking und iOutBank untersucht. Beide übertragen die Daten sicher. Die PayPal-App ist sicher bis auf denselben Fehler wie unter Android: Sie verschickt bei Verwendung des Bump-Features die als Kontonummer dienenden E-Mail-Adressen im Klartext. Die offizielle eBay App hingegen verzichtet auf Datenverschlüsselung, sodass Lauscher etwa Suchanfragen und Auktionsinhalte abhören können.

Die Notizbuchanwendung Evernote und die Dateisynchronierungs-App Dropbox sind auch auf dem iPhone nicht sicherer als unter Android: Die Logins sind verschlüsselt, aber unseren Sniffern gingen Notizinhalte beziehungsweise Nutzerdaten und zum Teil auch Dateiinhalte ins Netz.

Gegen unachtsame Programmierer, deren Apps wichtige Daten im Klartext verschicken oder Zertifikate nicht ordentlich prüfen, ist freilich kein Kraut gewachsen. Datenschlampen gibt es für Android und iPhone gleichermaßen. Dennoch lässt sich an den Testergebnissen ein Muster ablesen: das iPhone hat bei der Sicherung seiner Datenübertragung die Nase vorn. Wenn iPhone-Apps verschlüsseln, dann ordentlich. Unter Android scheint jede App ihr eigenes SSL-Süppchen zu kochen und mehrere getestete Apps verzichteten gleich ganz auf verschlüsselte Logins.

Doch ob Google oder Apple – Mobilanwendungen gibt es wie Sand am Meer und mit jeder installierten App steigt die Wahrscheinlichkeit, dass wichtige Daten ungesichert umhergefunkt werden. Wer wirklich sichergehen möchte, dass sich die Datenübertragung nicht abhören oder manipulieren lässt, sollte ein Virtuelles Privates Netzwerk einrichten. Wie das geht, beschreibt zum Beispiel der Online-Artikel „Fernweh, VPN für Smartphones“ auf heise Security [2].

  1. OpenBSC, Open-Source-Software für GSM-Netze, http://openbsc.osmocom.org
  2. Christiane Rütten, Fernweh [2], VPN für Smartphone, heise Security 2010

Netzwerksicherheit von Android-Applikationen
Anwendung Version SSL-
Zertifikats-
prüfung
Login-
Verschlüs-
selung
Daten-
verschlüs-
selung
Verwendete Ports Abgefangene Daten
Systemdienste
Chrome Browser 7 v v v 443, 80, …8
Google Market 1713 v v 80, 5228, 443 Suchbegriffe, Paketdaten
Google Sync 7 v v v 443,833 Name des Google-Kontos
E-Mail und Instant Messenger
AIM 1.7.5.1 1 2 80,44 Nachrichten, Kontaktnamen, Sitzungsdaten
E-Mail 7 v4 v4 v4 995, 993, 143, 110, 25 (Nutzername, Passwort, E-Mails)4
Google Mail 130 v v v 443
Google Talk 130 v v v 5228
K-9 Mail 3001 v4 v4 v4 995, 993, 143, 110, 25 (Nutzername, Passwort, E-Mails)4
Mail für HTC-Sense 2.0.37 v4 v4 v4 995, 993, 143, 110, 25 (Nutzername, Passwort, E-Mails)4
Meebo 22 v v v 443
Soziale Netzwerke
Facebook 1.03.02 v v 443,80 Kontaktdaten, Nachrichteninhalte
Seesmic 1.04.02 v v v 443
Twitter 1.0.15 80 Nutzername, Passwort, Nachrichten
Twidroyd Pro 3.04.06 v v 443 Nutzername, Passwort, Nachrichten
Xing 1.01.00 v v v6 443,80 Bilder
Banking und Shopping
PayPal 2.0.0 v v v 443,807 Nutzername, (E-Mail-Adresse)7
Pocket Auctions für eBay 2.0.9 2 80 Nutzername, Auktionsinhalte
S-Banking 1.5.0 v v v 443
Allgemein
Dropbox 0.9.8.6 v v 443,80 Dateiinhalte, Dateinamen, Nutzername, E-Mail-Adresse, Sitzungsdaten
Evernote 1.05.10 v v 443,80 Suchbegriffe, Notizen
1 Facebook-Login sicher, bleibt bei Angriff hängen
2 Passwort nicht im Klartext
3 für Facebook-Login
4 Verschlüsselung optional, Voreinstellung unsicher
5 Verschlüsselung ab 1.0.2/ Android 2.2 8
6 größtenteils verschlüsselt
7 bei Verwendung von Bump
8 je nach Website / Anwendung
v vorhanden
– nicht vorhanden

Netzwerksicherheit von iPhone-Applikationen
Anwendung Version SSL-
Zertifikats-
prüfung
Login-
Verschlüs-
selung
Daten-
verschlüs-
selung
Verwendete Ports Abgefangene Daten
Systemdienste
AppStore / iBooks iOS 4.0.3 v v 443,8 Paketdaten, Suchanfragen
iPhone Push iOS 4.0.3 v v v 5223
Safari Browser iOS 4.0.3 v v v 443, 80, …
E-Mail und Instant Messenger
Mobile Mail iOS 4.0.3 v v1 v1 995, 993, 143, 110, 25 (Nutzername, Passwort, E-Mails)1
Meebo 1.2.34496 v v v2 443,80
Soziale Netzwerke
Echofon 3.1.4 v v v3 443,80 Sitzungsdaten
Facebook 3.2.2 v v 443,80 Nachrichten, Kontaktnamen, Sitzungsdaten
Twitter 3.0.3a v v v 443
Xing 2.1.1 v v v2 443,80 Bilder, Sitzungsdaten
Banking und Shopping
eBay App 1.7.2 v v 443,80 Nutzername, Suchanfragen, Auktionsinhalte
iOutBank 2.6.34.1 v v v 443
PayPal 2.3.0.101 v v v2 443,80 Nutzername, (E-Mail-Adresse)4
S-Banking 1.5.1 v v v 443
Allgemein
Evernote 3.3.8 v v 443,80 Notizen, Suchbegriffe
Dropbox 1.2.5 v v 6 443,80 Dateiinhalte, Dateinamen, Nutzername, E-Mail-Adresse, Sitzungsdaten
1 je nach Server, Default sicher
2 größtenteils verschlüsselt
3 Verschlüsselung optional, Default unsicher
4 bei Verwendung von Bump
5 je nach Website / Anwendung
6 teilweise verschlüsselt
v vorhanden
– nicht vorhanden

Die meisten Android-Telefone enthalten den E-Mail-Client von Google oder den Mail-Client der HTC-Sense-Oberfläche, mit denen man auf beliebige Mailserver zugreifen kann. Aber Vorsicht: Deren Voreinstellung ist eine unverschlüsselte Verbindung, über die die Login-Daten im Klartext wandern. Wem Passwort und E-Mails lieb sind, der muss die Verbindungseinstellung TLS oder SSL setzen. Beide Verschlüsselungsoptionen gibt es bei „E-Mail“ mit dem Zusatz „Alle Zertifikate akzeptieren“, mit der das Programm zwar eine verschlüsselte Verbindung aufbaut, aber auf Zertifikatchecks verzichtet. Mit einem MITM-Angriff konnten wir Daten und Passwörter abgreifen. Das Schlimme: Der Nutzer hat keine Chance, den Angriff zu bemerken. Von diesem Zusatz sollte man daher unbedingt die Finger lassen.

Lassen Sie sich von dem Verschlüsselungszusatz „falls verfügbar“ nicht in die Irre führen: Er deaktiviert sämtliche Sicherheits-Checks und macht die Verschlüsselung im Ernstfall wertlos.

Lassen Sie sich von dem Verschlüsselungszusatz „falls verfügbar“ nicht in die Irre führen: Er deaktiviert sämtliche Sicherheits-Checks und macht die Verschlüsselung im Ernstfall wertlos.

Wer einen privat betriebenen Mailserver nutzen möchte oder auf den Firmenserver zugreifen will, schaut mit „E-Mail“ in die Röhre, wenn diese ein selbstsigniertes Zertifikat verwenden. Eine sichere Verbindung ist zu solchen Servern nicht möglich. „Mail“ bietet bei unbekannten Zertifikaten zwar die Option „Ignorieren“, aber das funktionierte im Test unzuverlässig und ist daher nicht empfehlenswert. K-9 Mail – gewissermaßen die Entwicklerversion von Android E-Mail mit verbessertem IMAP-Support und einer Reihe erweiterter Konfigurationsmöglichkeiten – bietet dem Anwender bei unbekannten Serverzertifikaten die Möglichkeit, unbekannte Zertifikate dauerhaft zu akzeptieren und trotzdem zu überprüfen. Die Option zum Akzeptieren beliebiger Zertifikate heißt bei K-9 irreführend „falls verfügbar“ – auch hier gilt: Finger weg!

Beim Einrichten des E-Mail-Kontos kann es auch zu Problemen kommen, wenn der angegebene Servername nicht mit dem im Zertifikat übereinstimmt. Verwendet man beispielsweise analog zur @gmx.de-Adresse als Server für eingehende Mails imap.gmx.de, meckert der Mailer das Zertifikat als ungültig an, weil es auf imap.gmx.net ausgestellt ist. Schauen sie in solchen Fällen in der Dokumentation ihres E-Mail-Providers nach den korrekten Servernamen, aber lassen Sie sich nicht zu dazu hinreißen, den Zertifikatscheck oder gar die Verschlüsselung komplett abzuschalten.

(cr [4])


URL dieses Artikels:
https://www.heise.de/-1901539

Links in diesem Artikel:
[1] ?anchor=android-Mail
[2] https://www.heise.de/hintergrund/Fernweh-1069090.html
[3] 
[4] mailto:cr@ct.de