Mythen rund im Internetsicherheit auf Reisen
- Starter*in Travelling_Geek
- Datum Start
ANZEIGE
Ich bin mir nicht ganz sicher, ob das Folgende in allen Fällen korrekt ist, oder je nach Konfiguration abweicht. Daher mit ein wenig Vorsicht genießen:
Der VPN-Client kann sich vom VPN-Gateway durchaus eine eigene DNS-Adresse zuweisen lassen beim Verbindungsaufbau. Das heißt aber nicht, dass alle DNS-Anfragen dann auch in den Tunnel gehen. Ich kann z.B. auf meiner Windows-Möhre über die Windows-eigene VPN-Funktion einen Tunnel aufbauen (samt eigener DNS-Zuweisung durch den VPN-Betreiber), aber dennoch weiterhin Namen in meinem lokalen Netzwerk auflösen lassen durch den DNS in der Fritzbox. Mein Rechner schickt die Anfrage also offenbar an alle ihm bekannten Nameserver. Sollte es hier Prioritäten geben im OS, dann könnte Dir der Tunnel mal so gar nix nutzen (weil dann der Traffic zwar verschlüsselt zum VPN-Gateway geht, von dort aufgrund der vergifteten IP aber doch wieder zum Phisher).
Es gibt aber einen erheblich besseren Schutz in diesem Zusammenhang: Zumindest kurzfristig die DNS-Einstellung von Hand ändern am eigenen Rechner / Smartphone und den von Google (8.8.8.8) eintragen. Dann zieht sich der Rechner (VPN oder kein VPN) nicht die IP vom vergifteten DNS des Hotspot-Betreibers, sondern schickt alle Anfragen raus an Google.
Ob man diese Einstellung dauerhaft so lassen (und Google so ein wirklich lückenloses Surfprofil in die Hand geben will), oder nur temporär nutzen will, ist eine Einzelentscheidung.
Travelling_Geek;2222432 Aber: Auch TLS/SSL beherrschen "Mutual Authentication" (Zertifikate auf beiden Seiten; passiert IMHO momentan aber in keiner Browser-basierten Anwendung) [/QUOTE meinte:
Er kann Dich per DNS-SPoofing zum Beispiel auf einen falschen Server umlaeiten, der u.U. sogar mit IDN einen Lookalike-Namen mit gültigen Zertifikat hat.
Und natürlich kann ein fortgeschrittener Angreifer die DNS-Anfragen an google auch abfangen und faken, bzw. gespoofed schneller beantworten.
Das Zertifikat ist ja auf den CName nicht auf die IP ausgestellt. Eines der Probleme ist halt, dass jede CA für jede Domain Zertifikate ausstellen darf. Die DNS-Erweiterung dies einzugrenzen sind leider nicht sehr weit im Einsatz (CAA und DANE).
Siehe Beitrag #123
Ja ich habs dann gesehen
Lese halt europäisch von oben nach unten...
Zuletzt bearbeitet:
Aber nur mit wahnsinnig hohem Aufwand und quasi der Garantie, dass das auffällt. Siehe hier: https://developers.google.com/speed/public-dns/docs/security
Wenn er sie abfängt, und DNSSEC abschaltet, fällt das in der Regel nicht auf. Schneller antworten wird schieriger, das stimmt. Aber auf dem GW, allen DNS-Traffic umleiten ist kein Hexenwerk.
Zuletzt bearbeitet:
Für ne IDN-Domain wirst Du die bei "Honest Achmed" auch bekommen. Und selbst "seriöse" CAs haben da schon geschlampt.
Und wer schaut schon aufs grüne Schloss.
So was https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/ kann helfen - aber nur bei gleichem CN, bei nem IDN hilft das nicht.
Ja, ein Blick auf die EV-Angaben genügt. Bzw macht es Dir Browser ohnehin einfach, weil er den Namen des Seitenbetreibers in voller Länge anzeigt (bei normalen TLS-Zertifikaten siehst Du nur "Sicher + Schlossicon" oder sowas.
Das ist eines der größten Probleme bei SSL/TLS von Beginn an: Es gibt quasi keine vertrauenswürdigen CAs (Aussteller). Selbst die großen wie Symantec/VeriSign pfuschen (Google akzeptiert in Chrome ab 2018 eine riesige Anzahl älterer von VeriSign ausgestellter Zertifikate nicht mehr; das wird lustig). Und bei den kleinen weiß man auch nie, ob die bei Trost sind (siehe Skandal um "DigiNotar"). Und dann betreiben die Regierungen von so illustren Staaten wie der Türkei, Saudi Arabien oder China CAs, denen jeder Windows-Rechner (und damit jede darauf laufende Anwendung) vertraut.
Das System basiert auf "Vertrauen", was von Haus aus eine doofe Idee ist
Ja, ein Blick auf die EV-Angaben genügt. Bzw macht es Dir Browser ohnehin einfach, weil er den Namen des Seitenbetreibers in voller Länge anzeigt (bei normalen TLS-Zertifikaten siehst Du nur "Sicher + Schlossicon" oder sowas.
Anhang anzeigen 97959
Das ist eines der größten Probleme bei SSL/TLS von Beginn an: Es gibt quasi keine vertrauenswürdigen CAs (Aussteller). Selbst die großen wie Symantec/VeriSign pfuschen (Google akzeptiert in Chrome ab 2018 eine riesige Anzahl älterer von VeriSign ausgestellter Zertifikate nicht mehr; das wird lustig). Und bei den kleinen weiß man auch nie, ob die bei Trost sind (siehe Skandal um "DigiNotar"). Und dann betreiben die Regierungen von so illustren Staaten wie der Türkei, Saudi Arabien oder China CAs, denen jeder Windows-Rechner (und damit jede darauf laufende Anwendung) vertraut.
Das System basiert auf "Vertrauen", was von Haus aus eine doofe Idee ist
Eben wenn eine schlechte CA ein EV austellt für dkb.de oder ein lookalike, hilft auch das nicht.
Zuletzt bearbeitet:
Dann würde ja etwas anderes dort stehen als "Deutsche Kreditbank Aktiengesellschaft" beim EV-Zert.
Ist das eigentlich noch aktuell acht Jahre später? Oder ist einer UMTS/LTE-verbindung eine (VPN-)WLAN-Verbindung vorzuziehen?
Solange Du nicht Merkel heißt oder Zetsche und Dein Job weder Bundeskanzlerin, noch Vorstandschef ist, bist Du mit 3G/4G weiterhin gut bedient.
Ja. Das ist zwar stark vereinfacht, aber WLAN ist deutlich unsicherer als von Providern angebotene Verbindungen.
Das liegt schlicht an dem zu betreibenden Kostenaufwand, in die Kommunikation einzudringen.
Bei WLAN praktisch ohne Kosten, nur Zeit und KnowHow, bei GSM basierenden Netzen >10.000€.
VPN, vernünftig eingerichtet, ist in Echtzeit nur durch staatliche Stellen zu knacken.
Also immer Empfehlenswert.
Je nachdem vor wem Du Deine Kommunikation verbergen willst oder mußt, sind die o.g. Maßnahmen aber zu schwach.
Ist das noch aktuell?
Die Lösung für das Problem wird im heise Artikel erklärt. Dadurch erkennt man an der URL, dass es eine Phishing Seite ist.
Oder reicht das nicht aus?
"Firefox-Anwender können die Darstellung von IDNs abschalten, indem sie in den erweiterten Browser-Einstellungen (about:config) den Wert des Schlüssels "network.IDN_show_punycode" auf "true" setzen."
Im Prinzip ist alles in diesem Thread auch nach 10 Jahren noch aktuell, ja.
Was sich in den letzten Jahren getan hat:
- SSL/TLS hat sowohl bei Webseiten als auch bei anderen Diensten (E-Mail etc) eine deutlich höhere Verbreitung bekommen, so dass viel weniger Verkehr unverschlüsselt über ein WLAN geht als früher
- zumindest einige Browser haben inzwischen eine https first Voreinstellung. Rufst du www.dkb.de auf, und gibst nicht explizit http:// davor ein, macht er https
Aber: Das ändert trotzdem nichts daran, das wenn du durch manipulierte DNS Antworten auf einen Fake-DKB-Server geleitet wirst, der kein https anbietet, dein Browser dann trotzdem HTTP versuchen wird. Wenn er das tut, kann dich dieser Fake Server unbemerkt (weil kein Zertifikatsaustausch stattfindet) auf www.dkbbanking.de weiterleiten (also irgendwas, das nach DKB aussieht, es aber nicht ist). Und da kann dann wieder https ins Spiel kommen (wenn der Angreifer ganz regulär diese dkbbanking.de-Domain registriert, kann er auch ganz regulär ein SSL-Zertifikat dafür bekommen).
Und dann hast du auch wieder dein grünes Schloss drin etc und merkst nix.
- es gibt Ansätze wie zum Beispiel dns-over-TLS/DNS over https, m.W. vom Firefox standardmäßig genutzt. Das würde zumindest im großteil das oben genannte Problem manipulierter DNS-Einträge lösen. Konkret der Firefox Ansatz mit CloudFlare als DNS Provider im Hintergrund ist aber aus anderen Gründen jetzt auch nicht unbedingt jedermanns Geschmack.
Ein VPN ist daher weiterhin - wenngleich auch nicht perfekt - immer noch meine dringende Empfehlung.
Was sich in den letzten Jahren getan hat:
- SSL/TLS hat sowohl bei Webseiten als auch bei anderen Diensten (E-Mail etc) eine deutlich höhere Verbreitung bekommen, so dass viel weniger Verkehr unverschlüsselt über ein WLAN geht als früher
- zumindest einige Browser haben inzwischen eine https first Voreinstellung. Rufst du www.dkb.de auf, und gibst nicht explizit http:// davor ein, macht er https
Aber: Das ändert trotzdem nichts daran, das wenn du durch manipulierte DNS Antworten auf einen Fake-DKB-Server geleitet wirst, der kein https anbietet, dein Browser dann trotzdem HTTP versuchen wird. Wenn er das tut, kann dich dieser Fake Server unbemerkt (weil kein Zertifikatsaustausch stattfindet) auf www.dkbbanking.de weiterleiten (also irgendwas, das nach DKB aussieht, es aber nicht ist). Und da kann dann wieder https ins Spiel kommen (wenn der Angreifer ganz regulär diese dkbbanking.de-Domain registriert, kann er auch ganz regulär ein SSL-Zertifikat dafür bekommen).
Und dann hast du auch wieder dein grünes Schloss drin etc und merkst nix.
- es gibt Ansätze wie zum Beispiel dns-over-TLS/DNS over https, m.W. vom Firefox standardmäßig genutzt. Das würde zumindest im großteil das oben genannte Problem manipulierter DNS-Einträge lösen. Konkret der Firefox Ansatz mit CloudFlare als DNS Provider im Hintergrund ist aber aus anderen Gründen jetzt auch nicht unbedingt jedermanns Geschmack.
Ein VPN ist daher weiterhin - wenngleich auch nicht perfekt - immer noch meine dringende Empfehlung.
Ich bin ein total unwissender Mensch in diesen Bereich, daher ein paar Fragen?
Ich möchte, dass in meiner Adressleiste im Browser (Firefox) die wahre Adresse angezeigt wird.
Die wahre Adresse mit lateinischen Schriftzeichen - das funktioniert dann mit dem "den Wert des Schlüssels "network.IDN_show_punycode" auf 'true' setzen", richtig?
Und "wahre" Adresse meine ich jetzt die, die wirklich aufgerufen wird.
Was muss ich dafür einstellen?
Ich möchte, dass in meiner Adressleiste im Browser (Firefox) die wahre Adresse angezeigt wird.
Die wahre Adresse mit lateinischen Schriftzeichen - das funktioniert dann mit dem "den Wert des Schlüssels "network.IDN_show_punycode" auf 'true' setzen", richtig?
Und "wahre" Adresse meine ich jetzt die, die wirklich aufgerufen wird.
Was muss ich dafür einstellen?
Sollte sich die Frage auf das Thema SSL/TLS beziehen: Per se würde der Angriff auch heute noch so funktionieren. Unter Umständen sogar schlagkräftiger als noch vor ein paar Monaten, da Safari (iOS & Desktop), Chrome (Mobil & Desktop) und Firefox (ditto) seit ein paar Wochen die Zusatzinfos der EV-Zertifikate nicht mehr direkt anzeigen. Sondern erst nach Klick auf das Schloss-Icon (das übrigens schon lange nicht mehr grün ist...).
Googles Begründung ist ziemlich ernüchternd: Anwender haben eh nicht kapiert, warum da manchmal der Unternehmensname links vom Schloss/der URL steht und manchmal nicht. Die haben auch beim Fehlen des Namens munter Daten auf Phishing-Seiten eingetragen (es war ohnehin eine beknackte Idee, das FEHLEN eines visuellen Elements als Hinweis auf irgendwas Sicherheitsrelevantes zu verwenden; das haben die Browser-Hersteller genauso verkackt wie diese unsägliche TLS-Fehlermeldung, die garantiert keinem Anwender auf dieser Erde hilft, die richtige Entscheidung zu treffen).
Zu diesen Unicode-Stunts: Die funktionieren per se natürlich immer noch. IMHO genügt es, wenn das Opfer vor dem Klick auf den vergifteten Link sicher ist, dass die URL schon passt. Ist die Phishing-Seite gut gemacht, guckt nach deren Aufbau doch keiner mehr in die Adresszeile (in der dann inzwischen ziemlich deutlich wird, dass da was nicht passen kann)...
Beispiel gefällig? Bitteschön.
http://vіelfliegertreff.de
Hättest Du ohne Mouse Over vor dem Klick gesehen, dass das eine Phishing-URL ist?