Kann jemand ein paar Zeile schreiben oder einen Link posten, zum Thema E-Mails abrufen in fremden WLANs? Hintergrund: Wenn über das WLAN eines gemieteten Ferienhaus E-Mails via Notebook abgerufen werden, ist dann Thunderbird oder ein Webinterface (web.de) sicherer?
Webmail über HTTPS darf man als sicher betrachten. POP3/IMAP über TLS ist ebenfalls sicher, wenn der Client das Zertifikat kontrolliert. Man sollte sofortiges SSL statt StartTLS verwenden.
Ingo schrieb: > Kann jemand ein paar Zeile schreiben oder einen Link posten, zum Thema > E-Mails abrufen in fremden WLANs? > > Hintergrund: Wenn über das WLAN eines gemieteten Ferienhaus E-Mails via > Notebook abgerufen werden, ist dann Thunderbird oder ein Webinterface > (web.de) sicherer? Falls Du Angst vor der Exekutive hast, so ist das völlig egal - denn von denen wird an der Stelle abgegriffen, an der bereits entschlüsselt wurde. D.h. die bekommen es so geliefert, wie es auch für Dich zum Lesen entschlüsselt wurde. Und falls Du web.de nutzt, musst Du Dir ohnehin keine Sorgen machen - denn das ist doch wirklich ein riesiges Spam und Virenverteilsystem.
Ingo schrieb: > Hintergrund: Wenn über das WLAN eines gemieteten Ferienhaus E-Mails via > Notebook abgerufen werden, ist dann Thunderbird oder ein Webinterface > (web.de) sicherer? JA, eigentlich schon. Wenn du die Übertragung über eine Sichere Verbindung machst. SSL ist hier das Zauberwort. Aber 100 % sicher ist grundsätzlich nix. Da deine Email - Passwort genau so wichtig ist, wie der Zugang zu deinen Bankkonto würde ich es trotzdem nicht machen. Lieber zahle ich ein paar Euro für den Datentraffic und mache es über das Handy-Netz. Wenn ich größere Mengen an Daten verarbeiten muss, würde ich das über ein VPN Routen der bei mir zu Hause steht. Was dann bedeutet würde Doppelte Verschlüsselung. Und der "Mann-in-the-Middle" kann mithören. Das ist mit etwas Aufwand sogar bei SSL-Verschlüsselungen möglich. ;)
Wenn du im Maklclient SSL/TLS aktiviert hast, sollte es sicher sein und der WLAN-Betreiber sieht nur noch die DNS-Anfrage und teile des Verbindungsaufbau. Je nachdem wie gut Thunderbird die Zertifikate prüft kann eine gezielte MITM-Attacke aber funktionieren. In dem Fall ist ein vertrauenswürdiges VPN hilfreich. Die Fritzboxen können das z. B. oder du kommandierst einen Raspberry Pi zum Wireguard-Server ab. Funktioniert auch mit dem Zero verdammt gut. Ist dann halt jeweils nur so schnell wie dein Upload minus Overhead.
Walter K. schrieb: > Und falls Du web.de nutzt, musst Du Dir ohnehin keine Sorgen machen - > denn das ist doch wirklich ein riesiges Spam und Virenverteilsystem. Ich denke es geht hier nicht um die Sicherheit von web.de als Mailanbieter generell, oder um den Staat, sondern um die Strecke zwischen PC/Handy und Anbieter über ein fremdes WLAN
- darauf achten dass das WLAN verschlüsselt ist Ja, ich hab z.B. in Dänemark auch schon Häuser gehabt wo der WLAN Zugang nicht verschlüsselt war... den Rest wurde schon gesagt...
Chris R. (ohne login) schrieb: > und der WLAN-Betreiber sieht nur noch die DNS-Anfrage Auch das muss nicht mehr sein, in Zeiten von DNS über verschlüsseltes Protokoll. Man hat in den gängigsten Varianten dann zwar Cloudflare oder Google mit im Boot, nicht aber neugierigen Junior des Vermieters.
:
Bearbeitet durch User
Beitrag #6800828 wurde vom Autor gelöscht.
Marc G. schrieb: > Ja, ich hab z.B. in Dänemark auch schon Häuser gehabt wo der WLAN Zugang > nicht verschlüsselt war... Ich hatte das einmal umgekehrt. Das WLAN war normal verschlüsselt, aber es war das Netz des Vermieters, nicht davon getrennt. Dessen privater Drucker tauchte automatisch in meinem Notebook auf. Es gab auch noch ein paar andere Adressen, darunter IoT Geräte.
(prx) A. K. schrieb: > Chris R. (ohne login) schrieb: >> und der WLAN-Betreiber sieht nur noch die DNS-Anfrage > > Auch das muss nicht mehr sein, in Zeiten von DNS über verschlüsseltes > Protokoll. > > Man hat in den gängigsten Varianten dann zwar Cloudflare oder Google mit > im Boot, nicht aber neugierigen Junior des Vermieters. Wenn der WLAN-Betreiber fit ist, unterbindet er einfach bestimmte Verschlüsselungen. Erkennt er DNS-over-TLS und blockiert diese, wird der Browser oder Client meist auf normales DNS zurückfallen, da es für alle Nutzer gedacht ist. Profis müssen dann in den Tweaks rumeditieren und das beheben. Ebenso bei IMAP und POP3. Flasch konfigurierter Client ermöglicht Klartextverbindungen.
(prx) A. K. schrieb: > Das WLAN war normal verschlüsselt, aber > es war das Netz des Vermieters, nicht davon getrennt. Dessen privater > Drucker tauchte automatisch in meinem Notebook auf. Das nenne ich Service! Benutzung des Vermieter-Druckers eingeschlossen. Perfekt!
(prx) A. K. schrieb: > Das WLAN war normal verschlüsselt, aber > es war das Netz des Vermieters, nicht davon getrennt. Dessen privater > Drucker tauchte automatisch in meinem Notebook auf. VORSICHT im Hotel. Da kann kostenpflichtige Absicht sein. Ich war mal in einen Hotel wo in den WLAN-Bedingungen stand da die Nutzung des Druckers 50 Cent pro Seite kostet, bei den Ausdruck von Fotos 1 Euro. Meinen Drucker ist der Zugang zum Netzwerk aus Kostengründen gesperrt. Ich will keinen heimlichen Firmware-Updates. ;). Ich habe extra eine Gruppe in der FB eingerichtet die 0 Online-Zeit bekommt. ;)
> POP3/IMAP über TLS ist ebenfalls sicher, wenn...
Problem ist halt, diese Protokolle stammen noch aus einer Zeit, als man
sich über Man in the middle Angriffe keine Gedanken machen musste.
Gibt inzwischen zwar Lösungen, die so sicher wie Https sind. Aber du
musst selbst kontrollieren, ob Client und Server die sicheren
Erweiterungen wirklich benutzen.
Wenn jemand einen Fehler im Https eines der 3 verbliebenen Brower
findet, geht es sofort durch alle Medien, wird sofort gefixt. Wenn
jemand einen Fehler im TLS des Thunderbird findet, der sich nur bei
wenigen IMAP Servern auswirkt - das interessiert niemanden. Davon
erfährst du nichts.
Der Opa aus der Muppet Show schrieb: > Problem ist halt, diese Protokolle stammen noch aus einer Zeit, als man > sich über Man in the middle Angriffe keine Gedanken machen musste. Nicht die Protokolle an sich sind das Problem, sondern Implementierungen davon, die nicht unbedingt auf Sicherheit gepolt sind.
:
Bearbeitet durch User
Hmmm... Protokolle in der Mehrzahl sind das Problem. Wenn du es deinem Client nicht explizit verbietet, können sich Client und Server auf prähistorisches POP3 ohne Verschlüsselung und Serverauthentifizierung einigen. Oder auf ein Protokoll, was schon seit 20 Jahren als unsicher gilt. Und das nächste Problem. Da sammeln sich alte Protokolle an, deren Implementierungen niemand mehr pflegt. Selbst wenn eine der Verschlüsselungen einwandfrei implementiert ist - Client und Server können sich auf alten Schrott einigen.
Marc G. schrieb: > darauf achten dass das WLAN verschlüsselt ist Muss nicht sein. Solange https/SSL/TLS benutzt wird, ist das auch in offenen WLAN ausreichend sicher geschützt*. *Vor Mithörern auf der WLAN-Strecke.
Der Opa aus der Muppet Show schrieb: > Wenn jemand einen Fehler im TLS des Thunderbird findet, der sich nur bei > wenigen IMAP Servern auswirkt - das interessiert niemanden. Davon > erfährst du nichts. Unter der Haube verwenden (fast?) alle eine der gängigen SSL/TLS-Implementationen, da muss man sich schon Mühe geben, um es zu verbocken. Das grösste Problem ist der User. Gerade in öffentlichen WLANs sollte man sich Warnmeldungen zum Zertifikat sehr genau durchlesen und im Zweifelsfall ablehnen. Einstellungen wie "SSL/TLS, wenn möglich" darf man natürlich keinesfalls aktivieren.
Der Opa aus der Muppet Show schrieb: > Wenn du es deinem Client nicht explizit verbietet, können sich Client > und Server auf prähistorisches POP3 ohne Verschlüsselung und > Serverauthentifizierung einigen. Das ist in den Mailclients problemlos explizit konfigurierbar, wenn es nicht sowieso schon vom Wizard so eingerichtet wird. Die üblichen Mailanbieter erlauben m.W. überhaupt kein unverschlüsseltes POP3/IMAP mehr. Aber natürlich ist Webmail der sicherste Weg für Leute, die sich in keiner Weise darum kümmern wollen.
:
Bearbeitet durch User
> da muss man sich schon Mühe geben, um es zu verbocken.
Leider erlauben die SSL/TLS Standards ein Dutzend Key exchange
Algorithmen. Ein Dutzend Verschlüsselungen und ein halbes Dutzend Hash
Algorithmen.
Wer hat da noch einen Überblick, welche Kombinationen von Algorithmen
und Implementierungen zur Zeit als sicher gelten? Und wer kann noch
beurteilen, ob Thunderbird alle relevanten Sicherheitspatches aller
verwendeten Libraries übernommen hat?
Der Opa aus der Muppet Show schrieb: > Wer hat da noch einen Überblick, welche Kombinationen von Algorithmen > und Implementierungen zur Zeit als sicher gelten? Die Programme und deren Konfigurationen, auf Client und Server evtl auch noch der einen oder anderen Firewall dazwischen. Ein uralter Internet Explorer kann zwar noch mit etwas Aussicht auf Erfolg den Inhalt von HTTP-Servern darstellen, wird aber bereits jetzt mit HTTPS an etlichen Servern scheitern. Weil so mancher Server nur noch TLS 1.2 aufwärts frisst, ohne Fallback, Tendenz zunehmend. Bei den enthaltenen Algorithmen ist das ähnlich. Auch da gibts in Libs wie OpenSSL im Prinzip zwar säckeweise Alternativen, aber viele davon stehen im Handshake auch auf explizite Anfrage nicht mehr zur Verfügung. Es gibt schon Gründe, weshalb man Programme ab und zu aktualisieren sollte. Selbst wenn sie nicht von Microsoft sind.
:
Bearbeitet durch User
Die Forenseite (oder deren Cloudflare) erlaubt sogar noch TLS 1.0: https://www.ssllabs.com/ssltest/analyze.html?d=www.mikrocontroller.net&s=104.26.12.250&latest Bei Heise geht nur noch TLS 1.1 aufwärts, was die Liste akzeptierter Clients schon drastisch reduziert (gegen Ende gelistet): https://www.ssllabs.com/ssltest/analyze.html?d=www.ix.de&s=193.99.144.80 Um ein A zu kriegen, darf auch kein TLS 1.1 mehr dabei sein: https://www.ssllabs.com/ssltest/analyze.html?d=fancyssl.hboeck.de&s=178.63.68.96 SSL Labs liegt bei dieser Client-Liste zwar nicht zu 100% richtig, ist aber schon mal ein Anhaltspunkt. Wer wissen will, was sein Client mitmacht: https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html
:
Bearbeitet durch User
Ingo schrieb: > Wenn über das WLAN eines gemieteten Ferienhaus E-Mails via > Notebook abgerufen werden, ist dann Thunderbird oder ein Webinterface > (web.de) sicherer? Egal, wenn der Vermieter geschickt Mini-Kameras installiert hat, die bei Dir quasi über die Schulter mitlesen.
Paranoia keeps the brain on spinning schrieb: > Egal, wenn der Vermieter geschickt Mini-Kameras installiert hat, die bei > Dir quasi über die Schulter mitlesen. Dann tippt man seine Passwörter und 2FA-Codes eben unterm Zelt ein. ;-)
Ich dachte, VPN und verschlüsseltes Webmail über ein aktuelles Browser würden in so einer Konstellation ausreichen. Tuen sie meiner Meinung nach auch.
> wo der WLAN Zugang nicht verschlüsselt war...
hat jeder ahnungslose Depp sein POP3-Passwort im Klartext
im Paket gehabt. Damit haette man damals dann auch per
SMTP Emails in seinem Namen verschicken koennen.
Private DNS finde ich auch nur gut, wenn ich selber einen
DNS-Proxy betreiben kann, der seine Anfragen ganz normal
auf Port 53 empfaengt, und dann die DNS-Query bearbeitet
und ggfs. die Daten per https besorgt.
"Eingebautes" Private DNS hilft nur den Werbe- und Schnueffelfirmen
wie Google, Apple, ....
> Erkennt er DNS-over-TLS und blockiert diese
Dazu muesste er "HTTPS-Tossing" betreiben.
Also https-Verbindungen aufbrechen und mit einem passend
gefaelschten Zertifikat on the fly neu signieren.
Und das kann man natuerlich feststellen.
Damit waere dieser Hotelbetreiber umgehend ein Fall fuer
die Staatsanwaltschaft.
Geruechteweise ist ein "Wildcard-Zertifikat" einer Root-CA
mal "entfleucht". Wenn das verbreitet wuerde, waere das das
Ende von https.
Jafrueher imHotel schrieb: > Geruechteweise ist ein "Wildcard-Zertifikat" einer Root-CA > mal "entfleucht". Wenn das verbreitet wuerde, waere das das > Ende von https. Oder es landet in den Browsern und Systemen in einer Sperrliste.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.