Mythen rund im Internetsicherheit auf Reisen

[weltspion]

ANZEIGE

Und was genau macht VPN besser als SSL?

Es handelt sich um unterschiedliche Ansätze: VPN baut einen verschlüsselten Tunnel zwischen zwei Netzwerken auf, die sich grundsätzlich vertrauen. SSL ist hingegen die reine Verschlüsselung einer Kommunikation, z.B. bei einem Aufruf einer Website durch einen unbekannten Aufrufer. VPN lassen sich u.a. mit SSL verschlüsseln.

SSL verschlüsselt mit 128bit, mit anderen Methoden geht mehr (z.B. VPN mit IPSec ermöglicht 256bit).

 

[hippo72]

Ergänzend dazu ist _mir_ keine Möglichkeit bekannt, wie man einen IPsec-VPN-Tunnel aufbrechen könnte.

Mit "aufbrechen" meine ich übrigens klassische SSL Inspection.

 

[Amino]

Wenn SSL so unsicher ist, warum verwenden die Banken das dann alle?

 

[phxsun]

Wenn SSL so unsicher ist, warum verwenden die Banken das dann alle?

Kryptographisch kann eine TLS-Verbindung eine vergleichbares Niveau wie eine VPN-Verbindung liefern, jedoch nur bezogen auf Client<->besonders sichere Website.
Jedoch liegen zwei Grundprobleme vor:
1. Nicht jede Website oder Dienst nutzt TLS (z.B. das VFT), damit werden ggf. ungesicherte Anmeldeinformationen über ungesicherte Netze übertragen.
2. Die Implementierungen bzw. Konfigurationen etlicher Webserver oder Dienste sind reudig. Damit sind dann die o.g. MitM Angriffe leicht möglich.
Wenn z.B. wirklich noch SSL statt TLS eingesetzt wird oder als Protokoll erlaubt ist, kann man die Verbindung als kompromittiert betrachten.

 

[phxsun]

Hast Du eine größere IT-Abteilung im Rücken, denen Du das schon mal schildern konntest? Falls ja, interessiert mich deren Einschätzung?


Hmmm... Soweit ich weiß, gibt es derzeit keinen funktionierenden MITM-Angriff auf EAS (Exchange Active Sync). Von daher wirkt diese mehrfache Abfrage merkwürdig. Aber auch hier wäre die Einschätzung der IT-Abteilung spannend (gern per PM)

Das klingt für mich nach Session Invalidation. Man versucht in die Session einzudringen, schafft es vermutlich eher nicht, trotzdem muss ich mich wieder anmelden, da das Session Token nicht mehr gültig ist.

 

[Travelling_Geek]

Wenn SSL so unsicher ist, warum verwenden die Banken das dann alle?

Weil es keine vergleichbare Technik gibt, die sich so (vergleichsweise) leicht nutzen lässt und so weit verbreitet ist. Wir reden ja über eine Technik die im ganzen Internet, das weit größer ist als "die paar Webserver", funktionieren muss, herstellerübergreifend. In dieser Hinsicht führt kein Weg an SSL/TLS vorbei, da keine andere Technik so gut skaliert.

SSL ist nicht per se unsicher, wenn die Serverbetreiber es ordentlich konfigurieren (was oftmals nicht der Fall ist, aber dafür kann ja SSL/TLS nix).
Es gibt diverse Angriffe auf SSL/TLS - die allesamt ins Leere laufen, wenn die Seitenadmins ihren Job machen. Meint: Die Menschen, die die weltweit gültigen Standards definieren und beim Bekanntwerden von neuen Angriffen jeweils nachbessern, machen ihre Hausaufgaben. Ob es die Seitenbetreiber auch tun, ist eine andere Geschichte.

Will ich mich in nicht vertrauenswürdigen Netzwerken also vor der eventuellen Nachlässigkeit der Seitenbetreiber schützen, schicke ich selbst TLS-verschlüsselten Traffic durch einen VPN-Tunnel.

 

[Amino]

Kann man da eigentlich irgendetwas dagegen machen, indem man die Zertifikate überprüft oder so? Oder ist VPN die einzige Möglichkeit?

Diese "SSL Inspection" bedeutet doch im Prinzip nichts anderes als ein Man in the Middle Angriff, also dass man mit einer anderen Person kommuniziert, als man denkt? Hab ich das richtig verstanden? Dann ist das doch im Prinzip kein Mangel an der Verschlüsselung, denn die Daten sind ja an sich super-verschlüsselt, man kommuniziert nur eben mit der falschen Person. Lässt sich das nicht irgendwie verhindern?

 

[Travelling_Geek]

Kann man da eigentlich irgendetwas dagegen machen, indem man die Zertifikate überprüft oder so? Oder ist VPN die einzige Möglichkeit?

Diese "SSL Inspection" bedeutet doch im Prinzip nichts anderes als ein Man in the Middle Angriff, also dass man mit einer anderen Person kommuniziert, als man denkt? Hab ich das richtig verstanden? Dann ist das doch im Prinzip kein Mangel an der Verschlüsselung, denn die Daten sind ja an sich super-verschlüsselt, man kommuniziert nur eben mit der falschen Person. Lässt sich das nicht irgendwie verhindern?

Ja, SSL Inspection ist quasi Man in the Middle durch einen von der Unternehmens-IT (ich lasse Fälle, bei denen staatliche Stellen mit dem Zeug hantieren, absichtlich außen vor) aufgestellten Proxy (inzwischen meist in Form einer Next Generation Firewall). Damit Dein Endgerät dem Proxy vertraut, wird einfach dessen Zertifikat auf jedem Endgerät in den Zertifikatsspeicher gelegt (als ob da nicht schon genug Mist drin liegen würde). Der Proxy baut eine TLS-Verbindung zum Kommunikationspartner Deines Endgeräts auf und entschlüsselt, Dein Endgerät baut eine TLS-Verbindung zum Proxy auf, der den Kram wieder verschlüsselt vor dem Versand.

Schutz hiervor: Ein SSL/TLS-eigener Mechanismus namens Certificate Pinning bremst auch unternehmensinterne SSL-Inspection aus. Meint: Die Seite wird einfach nicht geladen, der Browser gibt eine Sicherheitswarnung aus. Leider erfordert das Pinning ein fest im Browser hinterlegte Liste der URLs samt ihrer Zertifikate, so dass dies keine Lösung ist für https://www.tante-ernas-shop.de

 

[avgas]

Ja, SSL Inspection ist quasi Man in the Middle durch einen von der Unternehmens-IT [...] aufgestellten Proxy [...]. Damit Dein Endgerät dem Proxy vertraut, wird einfach dessen Zertifikat auf jedem Endgerät in den Zertifikatsspeicher gelegt [...]

Diese Art von Angriff erfordert allerdings vollen Zugriff auf den Rechner des Opfers, um dort die Einstellungen zu ändern und die Zertifikate zu installieren. Dagegen hilft übrigens auch kein VPN - der Rechner verbindet sich dann halt über das VPN mit dem "feindlichen" Proxy. Aber gegen Angreifer die bereits auf dem Rechner eingedrungen sind (wie die Firmen-IT ;-) gibt es sowieso keine wirksame Verteidigung.

Der Unterschied zwischen VPN und SSL ist hauptsächlich folgender:

• Ein VPN sichert alle Verbindungen, aber nur bis zum "Ausgang" des VPN
• SSL sichert nur eine Verbindung, aber immer über die komplette Strecke
• Die (Verschlüsselungs-)Technologie dahinter ist sehr, sehr ähnlich - von der Technik her gibt es da praktisch keine Sicherheitsunterschiede

Beispiel: Ich verbinde mich per Firmen-VPN mit meiner Bank und Spiegel Online. Dann ist die Verbindung bis zum Firmen-Netz für beide Fälle gesichert. Im lokalen WLAN sieht keiner, dass ich SPON lese. Die Verbindung von meinem Firmennetz "nach draussen" ist aber nicht mehr per gesichert.

Wenn ich kein VPN nutze, ist die Verbindung zur Bank immer noch per SSL gesichert - und zwar die komplette Strecke von meinem Rechner bis zur Bank. Was ich auf SPON lese, sieht man aber jetzt im lokalen Netzwerk.

Seit dem Ursprungsartikel ist im Bereich Netzwerksicherheit übrigens sehr viel passiert. Man kann zumindest bei den "grossen" Anbietern davon ausgehen (Google, Facebook, GMX, ...), dass die SSL-Verbindung sauber konfiguriert und sicher ist.

Wer es übrigens selbst überprüfen will, auch dafür gibt es ein Tool im Internet: https://www.ssllabs.com

 

[Travelling_Geek]

Diese Art von Angriff erfordert allerdings vollen Zugriff auf den Rechner des Opfers, um dort die Einstellungen zu ändern und die Zertifikate zu installieren.

Was ich so ja schon schrieb

Dagegen hilft übrigens auch kein VPN - der Rechner verbindet sich dann halt über das VPN mit dem "feindlichen" Proxy.

Natürlich hilft VPN hiergegen, wenn anstelle von X.509 zum Verbindungsaufbau zwischen Client und VPN-Endpunkt ein Pre Shared Key verwendet wird, den die NGFW (oder wer auch immer da den MiTM macht) nicht kennt.

Aber gegen Angreifer die bereits auf dem Rechner eingedrungen sind (wie die Firmen-IT ;-) gibt es sowieso keine wirksame Verteidigung.

Es ist ein großer Unterschied, ob eine Malware jede Tastatureingabe mitschneidet bzw. Screenshots anfertigt, oder ob die Firmen-IT ein paar Root-Zertifikate in den Speicher wirft...

Die (Verschlüsselungs-)Technologie dahinter ist sehr, sehr ähnlich - von der Technik her gibt es da praktisch keine Sicherheitsunterschiede

Das ist, mit Verlaub, Quark. Zwar gibt es SSL/TLS-basierte VPNs .
Gängig sind inzwischen jedoch IPSEC-VPNs und hier hat die Verschlüsselung mit SSL/TLS mal so gar nix gemeinsam. Das fängt schon bei den Algorithmen für den Schlüsselaustausch an, der bei TLS per Handshake (keine PSKs) und bei IPSEC per IKE (diverse Verfahren) stattfindet. Dann gehts weiter mit der eigentlichen Verbindung: IPSEC verschlüsselt erst und erzeugt dann den MAC der verschlüsselten Daten, TLS macht erst MAC vom Klartext und verschlüsselt dann. Und so weiter und so weiter.

 

[Amino]

Ich verstehe es immer noch nicht:

Wenn ich mich mit einem offenen Wlan verbinde und dann eine SSL/TLS-verschlüsselte Seite aufrufe (z.B. einer Bank) warum ist das dann angeblich unsicher?

Ich muss doch nicht davon ausgehen, dass die großen Banken bei der Verschlüsselung gepfucht haben?

 

[Travelling_Geek]

Ich muss doch nicht davon ausgehen, dass die großen Banken bei der Verschlüsselung gepfucht haben?

Das kommt ein bisschen auf Deinen Grad der Paranoia an beziehungsweise Dein Vertrauen in menschliche Unfehlbarkeit.
Es gab in der Vergangenheit durchaus Beispiele, bei denen Admins von Banking-Seiten beim Verwalten ihrer SSL/TLS-Zertifikate gepfuscht haben.
Und als die POODLE-Attacke vor über zwei Jahren bekannt wurde, brauchten Banken hierzulande vergleichsweise lange, ihre fürs HBCI verwendeten Server ordentlich zu konfigurieren (meint: SSLv3 zu unterbinden und nur noch auf TLS zu setzen)

Wenn Du den Server Deiner Bank mal grob auf die Qualität der TLS-Zertifikate testen willst: https://www.ssllabs.com/ssltest/index.html

 

[avgas]

Hallo,

ich versuche mal gleichzeitig zu antworten und noch etwas den "Tech Talk" zu erklären, dann lernt vielleicht noch jemand was, der/die nicht so tief drin ist - ist jetzt etwas länglich geworden, aber vielleicht findet es ja jemand interessant.

Was ich so ja schon schrieb

Natürlich hilft VPN hiergegen, wenn anstelle von X.509 zum Verbindungsaufbau zwischen Client und VPN-Endpunkt ein Pre Shared Key verwendet wird, den die NGFW (oder wer auch immer da den MiTM macht) nicht kennt.

Ich meinte nicht mal, dass man das VPN dafür knacken muss. Wenn Du einen Proxy und ein Root-Zertifikat auf dem Rechner installieren kannst, nimmst Du einfach einen Proxy der irgendwo im Internet liegt. Dann verbindet sich der Browser mit (durch das VPN hindurch) mit diesem Proxy, der dann den MiTM macht.

Andererseits: Wenn ich auf einem Rechner Zertifikate und Einstellungen ändern kann, könnte ich vermutlich auch den PSK auslesen und/oder austauschen.

Etwas Background:

Ein Pre-Shared-Key (PSK) ist ein Geheimnis (zum Beispiel ein sehr langes Passwort, oder eine Datei), das nur die beiden "Enden" des VPN kennen, also mein Rechner und die Gegenstelle. Damit können die beiden dann die Verbindung verschlüsseln, und beide können feststellen dass die andere Seite "echt" ist.

Das gibt es beim https (TLS/SSL) tatsächlich nicht - denn der Schlüssel muss vorher über eine sichere Verbindung übertragen werden (z.B. in dem der Admin ihn auf den Rechner kopiert). Vorteil für das VPN: Beide Seiten kennen und vertrauen sich. Wie eine Parole beim Militär: Wenn Du mir das geheime Passwort sagen kannst, weiss ich dass Du zu den Guten gehörst.

Beim SSL ist das nicht so, das sich die "Enden" vorher nicht kennen. Um zu wissen, ob eine Webseite wirklich echt ist, muss ich einen Dritten "fragen". Das sind die weiter vorne erwähnten CAs (Certificate Authority). Diese bestätigen, dass https://meinebank.de/ wirklich meiner Bank gehört, und nicht zu einem Betrüger. Das ist dann wie bei einem Pass: Der Staat hat Dir einen Pass ausgestellt. Weil ich dem Staat (zumindest in Bezug auf Pässe ;-) vertraue, glaube ich dass Du Du bist. Und weil die CA der Bank einen "Pass" ausgestellt habe, weiss ich das die Webseite echt ist.

SSL sagt der Bank allerdings nicht, dass ich "echt" bin - dafür muss erst noch mein Passwort eingeben.

Die eine hier geäußerte Befürchtung beim SSL ist jetzt, das eine CA falsche "Pässe" ausstellt. Wenn jetzt einer von den Bösen die so etwas hat, kann er so tun als wäre er meine Bank, und ich würde es nicht merken. Er könnte mir sogar die Seite von der Bank weiterleiten und der Bank meine Eingaben, und dabei alles mitlesen. Wie wahrscheinlich das ist, steht auf einem anderen Blatt.

Der andere Einwand gegen TLS/SSL ist, dass erste Version schon aus den 90er Jahren stammt. Seitdem wurden immer wieder Fehler und Schwächen entdeckt, und neue Versionen veröffentlicht um diese Fehler zu beheben. (Das ist durchaus nicht ungewöhnlich, und bei allen Produkten so). Wenn jetzt jemand die alten, schwachen Verfahren noch verwendet, ist diese Verbindung angreifbar. Wenn die neueste Version verwendet und richtig konfiguriert wird, dann ist es sicher.

Es ist ein großer Unterschied, ob eine Malware jede Tastatureingabe mitschneidet bzw. Screenshots anfertigt, oder ob die Firmen-IT ein paar Root-Zertifikate in den Speicher wirft...

Es ist natürlich ein großer Unterschied im Ergebnis (und natürlich gehe ich davon aus, dass die Firmen-IT normalerweise vertrauenswürdig ist ;-) Technisch sehe ich aber keinen großen Unterschied. Was ich will, ist normalerweise Zugriff auf den Speicher (RAM und/oder Festplatte). Wenn ich das erst mal habe kann ich Zertifikate installieren, oder Malware, oder andere Sachen.

Das ist, mit Verlaub, Quark. Zwar gibt es SSL/TLS-basierte VPNs .
Gängig sind inzwischen jedoch IPSEC-VPNs und hier hat die Verschlüsselung mit SSL/TLS mal so gar nix gemeinsam.

Ja und nein. Natürlich gibt es technische Unterschiede und die Protokolle setzen an komplett anderen Stellen an. Allerdings (und in die Richtung geht meine Antwort) gibt es auch keine "magische Sauce" beim VPN, die TLS/SSL nicht hat und die es deswegen sicherer macht. Das ist nicht so.

Beide verwenden bekannte Standard-Verschlüsselungsverfahren (und Hash-Verfahren). Beide verwenden kryptografische Standardverfahren, um die Gegenstelle zu identifizieren. Beide werden ständig auf mögliche Fehler untersucht und aktualisiert. Beide sind anerkannte Standards.

Der einzige wirkliche Unterschied ist, dass sich beim VPN (normalerweise) beide Seiten gegenseitig vertrauen (über PSK oder andere Verfahren). Beim TLS/SSL wird Vertrauen (normalerweise) über die CAs nur in eine Richtung hergestellt - siehe oben.

In der Theorie gibt das tatsächlich ein zusätzliches Vertrauen. Allerdings nur, wenn ich mich innerhalb des VPN befinde. Sobald ich mich "nach draussen" in das grosse weite Internet verbinde (was ja meist das Ziel ist), endet die zusätzliche Sicherheit "hinter" dem VPN.

Das ist übrigens auch der Grund, warum Banken/Webseiten kein VPN verwenden: Es erfüllt einen völlig anderen Zweck - und würde ich das VPN für den gleichen Zweck wie TLS/SSL einsetzen hätte es die gleichen Probleme.

Für den diskutierten Fall "Internet im Hotel":

• Es schützt wirklich gegen Angriffe aus dem WLAN gegen nicht oder schlecht gesicherte Seiten ohne TLS oder mit schlecht eingerichtetem TLS - die werden allerdings immer seltener.
• Es schützt nicht generell gegen Angriffe aus dem Internet, oder gegen Hacker die sich auf dem Rechner befinden.
• Es schützt nicht komplett gegen Angriffe aus dem WLAN auf den Rechner selbst: Daher sollte man immer die lokale Firewall aktivieren, und Netzwerkdienste (z.B. Dateifreigabe) abschalten.

Was auch zusätzlich schützt ist ein (Firmen-)VPN, dass über eine starke Firewall mit dem Internet verbunden ist. Aber das haben wohl die wenigsten...

Um zurück zum Topic zu kommen: Ein VPN ist tatsächlich ein Werkzeug für die Sicherheit auf Reisen. Wichtiger als die Diskussion SSL vs. VPN finde ich aber, dass man die Risiken kennt und ein sinnvolles "Gesamtpaket" hat.

Zum Beispiel:

• Alle Geräte (ja, auch die Telefone!) haben eine lange PIN bzw. ein sicheres Passwort und sperren sich automatisch
• Alle Geräte sind verschlüsselt (Festplatte auf dem Rechner verschlüsselt, Android-Verschlüsselung aktiviert)
• Die lokale Firewall ist aktiviert. Alle Netzwerkdienste (Drucker-/Dateifreigabe, Webserver, ...) sind abgeschaltet.
• Die Software ist auf dem neuesten Stand
• Wichtige Korrespondenz? -> Per verschlüsselter Email, oder per verschlüsseltem Messenger (nach "Vertrauenslevel": Signal, Threema, (Whatsapp wer ihm traut...), ...)
• Eigener WLAN/LTE/UMTS-Router? -> Die WLAN-Verschlüsselung sollte aktiv sein (und ein sicheres Passwort haben)
• Für Fortgeschrittene: Ein Netzwerk-Blocker (App Firewall) (TripMode für Mac/Windows oder Little Snitch für Mac, für andere Systeme gibt es sowas sicher auch) - damit kann man einzelnen Programmen die Internetverbindung kappen. Das ist auch hilfreich, um sein Datenvolumen zu schonen.
• Nicht über die Schulter schauen lassen
• Sich das Ding nicht klauen lassen
• Passwörter nicht mit PostIts am Rechner befestigen

 

[Travelling_Geek]

Hallo,

ich versuche mal gleichzeitig zu antworten und noch etwas den "Tech Talk" zu erklären, dann lernt vielleicht noch jemand was, der/die nicht so tief drin ist - ist jetzt etwas länglich geworden, aber vielleicht findet es ja jemand interessant.

Deinen Versuch in allen Ehren: Wissen vermitteln ist toll, solange das vermittelte Wissen präzise ist. In Deinem Post ist das leider nicht immer der Fall...

Ich meinte nicht mal, dass man das VPN dafür knacken muss. Wenn Du einen Proxy und ein Root-Zertifikat auf dem Rechner installieren kannst, nimmst Du einfach einen Proxy der irgendwo im Internet liegt. Dann verbindet sich der Browser mit (durch das VPN hindurch) mit diesem Proxy, der dann den MiTM macht.

Kennst Du eine Malware, die einen so komplizierten Weg geht? Nicht nur muss der Angreifer im Besitz eines Root-Zertifikats sein. Er muss zudem einen Server mit ordentlicher Anbindung (meint: kein Bot, sondern eher eine AWS-Instanz) über längere Zeit unbemerkt im Netz betreiben können.
Der gängige Weg ist die Installation eines lokalen Proxys durch die Malware auf der Maschine. SSL/TLS hebeln die Banking-Trojaner dann durch Man in the BROWSER aus, nicht durch MiTM. Das kostet nix und ist quasi unsichtbar (anders als eine AWS-Instanz).

Andererseits: Wenn ich auf einem Rechner Zertifikate und Einstellungen ändern kann, könnte ich vermutlich auch den PSK auslesen und/oder austauschen.

Viel zu kompliziert. Siehe oben.

Ein Pre-Shared-Key (PSK) ist ein Geheimnis (zum Beispiel ein sehr langes Passwort, oder eine Datei), das nur die beiden "Enden" des VPN kennen, also mein Rechner und die Gegenstelle. Damit können die beiden dann die Verbindung verschlüsseln

Nope. Der PSK dient nur dem Authentifizieren. Die Krypto-Schlüssel werden per IKE ausgetauscht.

Das gibt es beim https (TLS/SSL) tatsächlich nicht - denn der Schlüssel muss vorher über eine sichere Verbindung übertragen werden (z.B. in dem der Admin ihn auf den Rechner kopiert).

Das sollte besser heißen "bei einem VPN muss der PSK vorher übertragen werden".
Aber: Auch TLS/SSL beherrschen "Mutual Authentication" (Zertifikate auf beiden Seiten; passiert IMHO momentan aber in keiner Browser-basierten Anwendung)

Beim SSL ist das nicht so, das sich die "Enden" vorher nicht kennen.

Du meinst: Bei SSL kennen sich die Gesprächspartner vorher nicht.
Was aber eben auch nicht immer stimmt, siehe "Mutual Authentication"-

Die eine hier geäußerte Befürchtung beim SSL ist jetzt, das eine CA falsche "Pässe" ausstellt. Wenn jetzt einer von den Bösen die so etwas hat, kann er so tun als wäre er meine Bank, und ich würde es nicht merken. Er könnte mir sogar die Seite von der Bank weiterleiten und der Bank meine Eingaben, und dabei alles mitlesen. Wie wahrscheinlich das ist, steht auf einem anderen Blatt.

Unüblich ist es nicht. Jedenfalls wenn es um Kommunikation geht (Google Mail, Hotmail), an die man anders nicht rankommt. Für Online-Banking-Betrug gibts einfachere Wege (siehe oben).

Wenn die neueste Version verwendet und richtig konfiguriert wird, dann ist es sicher.

Macht nur leider kaum jemand, sowas ordentlich zu konfigurieren. IMHO war es im letzten Jahr ein Drittel aller Server, die sich per DROWN auf SSLv2 runterhandeln lassen...
Davon abgesehen: Logjam funktionierte auch mit aktuellen TLS-Versionen. Zumindest solange, bis die Browser/Clients gepatcht wurden.

Ja und nein. Natürlich gibt es technische Unterschiede und die Protokolle setzen an komplett anderen Stellen an. Allerdings (und in die Richtung geht meine Antwort) gibt es auch keine "magische Sauce" beim VPN, die TLS/SSL nicht hat und die es deswegen sicherer macht. Das ist nicht so.

Du schriebst oben "von der Technik her gibt es da praktisch keine Sicherheitsunterschiede"
Natürlich gibt es die. IPSEC ist aufgrund diverser Faktoren (zwingende Authentifizierung, fest eingetragene Gateways, keine Downgrade-Attacken (Logjam ist nur für NSA & Co ein Thema bei IPSEC)) erheblich schwieriger mitzulesen als TLS.
Übrigens: IPSEC ist eine ProtokollSAMMLUNG, kein Protokoll.

Beide verwenden bekannte Standard-Verschlüsselungsverfahren (und Hash-Verfahren). Beide verwenden kryptografische Standardverfahren, um die Gegenstelle zu identifizieren.

Yep. Und hier hat IPSEC mit dem (bislang) robusteren IKE die Nase vorn.Beide werden ständig auf mögliche Fehler untersucht und aktualisiert. Beide sind anerkannte Standards.

In der Theorie gibt das tatsächlich ein zusätzliches Vertrauen. Allerdings nur, wenn ich mich innerhalb des VPN befinde. Sobald ich mich "nach draussen" in das grosse weite Internet verbinde (was ja meist das Ziel ist), endet die zusätzliche Sicherheit "hinter" dem VPN.

VPN hat auch nicht die Aufgabe, jeden beliebigen Server zu authentifizieren. Es soll lediglich eine abhörsichere Verbindung in einem ansonsten unsicheren Netzwerk schaffen.
Von daher ist das "in der Theorie" fehl am platz.

Das ist übrigens auch der Grund, warum Banken/Webseiten kein VPN verwenden: Es erfüllt einen völlig anderen Zweck - und würde ich das VPN für den gleichen Zweck wie TLS/SSL einsetzen hätte es die gleichen Probleme.

Hä?
Was soll das genau bedeuten?
"Würde ich die Bohrmaschine für den gleichen Zweck einsetzen wie die Leiter, hätte sie die gleichen Probleme".

Für den diskutierten Fall "Internet im Hotel":
[*] Es schützt wirklich gegen Angriffe aus dem WLAN gegen nicht oder schlecht gesicherte Seiten ohne TLS oder mit schlecht eingerichtetem TLS - die werden allerdings immer seltener.

Nope. VPN schützt mal gar nicht gegen Heartbleed.

[*] Alle Geräte sind verschlüsselt (Festplatte auf dem Rechner verschlüsselt, Android-Verschlüsselung aktiviert)

Die Verschlüsselung nutzt nichts, wenn das Gerät im Stand-by ist. Nur herunterfahren hilft.

 

[Luftikus]

Da es auch um Mythen geht: Habe mal gehört, USB-Ladebuchsen im Flugzeug (und auch in Hotels) können das eigene Gerät unerkannt ausspähen, während man nur zu laden glaubt. Kann hier mal bitte ein Profi was dazu sagen?

 

[Airwalk]

Da es auch um Mythen geht: Habe mal gehört, USB-Ladebuchsen im Flugzeug (und auch in Hotels) können das eigene Gerät unerkannt ausspähen, während man nur zu laden glaubt. Kann hier mal bitte ein Profi was dazu sagen?

Ist durchaus mit jeder USB-Ladebuchse möglich, wenn entsprechende Technik dort implantiert wird. Ob mehr als "laden" mit der USB-Buchse möglich ist, merkt man z.B. bei Apple-Geräten, wenn das Gerät nach "Wollen Sie dem Computer vertrauen?" fragt, wenn man es an die USB-Buchse stöpselt.

Siehe auch: https://de.wikipedia.org/wiki/Juice_Jacking

 

[odie]

Wen du das Gerät "nur" Laden willst dann nimmst n Tesafilm und klebst die mittleren 2 Kontakte ab. USB hat 4 Kontakte, die äusseren beiden sind die Spannungsversorgung zum laden, die 2 mittleren sind die "Datenleitungen".

Bild geklaut bei Google

 

[Luftikus]

Danke.
Seitdem ich gesehen habe, dass sogar Zuckerberg seine Laptopkamera abklebt, mache ich das natürlich auch. Mein Mikro mache ich aber bisher noch nicht zu.

 

[avgas]

Deinen Versuch in allen Ehren: Wissen vermitteln ist toll, solange das vermittelte Wissen präzise ist. In Deinem Post ist das leider nicht immer der Fall...

Ehrlich gesagt: Es geht mir mehr um Allgemeinverständlichkeit als um Details. Ich habe keinen Zweifel, dass Du weisst wie IPSEC und TLS funktionieren. Aber hier ist kein Tech-Forum, und hier kommen dann Fragen wie "warum benutzt mein Onlinebanking kein VPN statt statt SSL, wenn das viel sicherer ist?"

Um Dein Beispiel mit der Leiter und der Bohrmaschine aufzugreifen: Das ist dann, als wenn jemand fragt "warum benutzt mein Klempner eine Bohrmaschine statt einer Leiter, obwohl man sich damit so leicht wehtun kann?"

In diesem Fall muss man erst mal verstehen, was der Unterschied zwischen einer Leiter und einer Bohrmaschine ist - wie die dann drin funktionieren ist erst mal zweitrangig. Das habe ich versucht. Kann sein dass es nicht perfekt gelungen ist; vermutlich geht es noch besser, kürzer und eingängiger, aber meine Zeit ist auch begrenzt ;-)

Worauf ich hinauswollte: TLS/SSL und (IPSEC-)VPNs sind beides sehr gute Lösungen für den jeweiligen Einsatzzweck. Diese Zwecke sind aber verschieden. Deswegen kann ich nicht einfach TLS durch ein VPN ersetzen, und TLS wird nicht dadurch besser oder schlechter, dass ich aus anderen Gründen irgendwo ein VPN benutze.

BTW: Deine technischen Anmerkungen oben sind völlig korrekt, deswegen gehe ich auch nicht noch mal darauf ein.

Kennst Du eine Malware, die einen so komplizierten Weg geht? ...

Viel zu kompliziert. Siehe oben.

Bevor es wieder in die Details geht: Keinen dieser Angriffe stoppe ich, indem ich per VPN ins Netz gehe. Darum ging es mir, nicht darum ob sich der Angriff gegen das VPN selbst richtet.

Du meinst: Bei SSL kennen sich die Gesprächspartner vorher nicht.
Was aber eben auch nicht immer stimmt, siehe "Mutual Authentication"-

Richtig, das war ein Schreibfehler.

Macht nur leider kaum jemand, sowas ordentlich zu konfigurieren. IMHO war es im letzten Jahr ein Drittel aller Server, die sich per DROWN auf SSLv2 runterhandeln lassen...
Davon abgesehen: Logjam funktionierte auch mit aktuellen TLS-Versionen. Zumindest solange, bis die Browser/Clients gepatcht wurden.

Wie gesagt, die "Grossen" machen das recht zuverlässig. Die "Kleinen" nicht immer. (Fun Fact: Dieses Forum hier nutzt gar keine Verschlüsselung... da könnte man im offenen WLAN tatsächlich ein paar Passwörter abgreifen ;-)

Die Verschlüsselung nutzt nichts, wenn das Gerät im Stand-by ist. Nur herunterfahren hilft.

Solange man nach dem Stand-By das Passwort braucht, ist es zumindest nicht ganz trivial, die Daten auszulesen. Und sobald ein Dieb das Ding einmal ausgeschaltet hat, sind zumindest die Daten sicher (so sicher, wie das Passwort).

 

[Amino]

Ehrlich gesagt verstehe ich es immer noch nicht.

Wieso ist SSL oder TLS in öffentlichen WLans nicht sicher? Wenn ich in einem öffentlichen WLan eine Bankseite aufrufe, zB. dkb.de, dann kann ich ja sogar auf das grüne Schloss klicken und ansehen, ob sich an dem Zertifikat etwas geändert hat. Wenn dann plötzlich als Zertifikat-Aussteller anstatt "Symantec Corporation" etwas ganz anderes stehen würde, dann wäre das doch auffällig.

Außerdem: Wenn mein Gerät nicht virenversäucht ist, wie soll dann überhaupt jemand, nur weil er im gleichen WLan ist, irgendwelche gefälschten Zertifikate installieren?

Leider gibt es hier bis jetzt niemanden, der mit verständlich erklären kann, warum SSL/TLS in öffentlichen Netzwerken unsicher ist...

 

[hannoi75]

Guckst Du hier:
http://www.elektronik-kompendium.de/sites/net/1906041.htm

 

[Amino]

Leider geht der Beitrag ziemlich an meiner Frage vorbei.

Meine Frage war, was ein möglicher Angreifer tun könnte, wenn ich in einem öffentlichen WLan beispielsweise eine Bankseite aufrufe.

Bei einer Bank werde ich wohl davon ausgehen können, dass sie nicht ihren privaten Schlüssel per E-Mail bekommen hat und dass sie auch nicht Zertifikate von pfuschenden Ausstellern verwenden.

Auch der hypothetische Fall, dass ein Geheimdienst den Aussteller zur Ausstellung falscher Zertifikate zwingt, hat mit meiner öffentliche-WLan-Frage nichts zu tun, denn wenn mich ein Geheimdienst ausspionieren will, dann würde er das wohl eher bei meiner privaten Internetverbindung zuhause tun, anstatt im Hotel-WLan.

 

[Travelling_Geek]

Wieso ist SSL oder TLS in öffentlichen WLans nicht sicher? Wenn ich in einem öffentlichen WLan eine Bankseite aufrufe, zB. dkb.de, dann kann ich ja sogar auf das grüne Schloss klicken und ansehen, ob sich an dem Zertifikat etwas geändert hat.

Ein Angrifsszenario sähe wie folgt aus (hat auch erstmal nix mit SSL/TLS zu tun, hebelt dessen Schutz aber auch aus):
- Der Anbieter des Hotspots betreibt einen manipulierten DNS. Dieser löst alle unkritischen Seitennamen brav auf und gibt die IP-Adressen der legitimen Seitenbetreiber (z.B. 213.148.99.21 für vielfliegertreff.de) an Deinen Rechner zurück, der die Seite dann im Browser darstellt.
- Wenn Du aber die Webseite Deiner Bank aufrufst, landest Du nicht bei der DKB, sondern durch den manipulierten DNS-Eintrag bei einem russischen Bullet Proof Hoster. Auf dem jemande eine Phishing-Seite betreibt, die aussieht wie die DKB-Seite (weil er einfach den Content der DKB-Seite kopiert und nur das Loginfeld manipuliert, um die Daten mitzuschneiden).
- Für die Domän dieser Phishing Seite hat sich der Angreifer ein Zertifikat ausstellen lassen. Von mir aus bei Symantec
- Wenn Du jetzt den Unterschied zwischen EV (Extended Validation)-Zertifikaten und Standard-Zertifikaten nicht kennst, merkst Du nicht, dass dem Angreifer-Zertifikat die für EV nötigen Angaben fehlen; diese Angaben erfragt die CA beim Seitenbetreiber und nur jemand von der DKB kann auch ein EV-Zertifikat für die DKB bekommen. Davon abgesehen weiß sowieso kein Mensch, welcher Webshop/welche Bank normalerweise EV nutzt und wer nicht. Betreiber wie die Postbank helfen auch nicht gerade, da sie auf "www.postbank.de" ein herkömmliches Zertifikat verwenden, auf "banking.postbank.de" aber ein EV-Zertifikat.
- Wie man ein Zertifikat für eine Domäne bekommt, die im Browser so aussieht (aussah) wie die der nachzuahmenden Seite, steht hier: https://www.heise.de/security/meldu...ing-per-Unicode-Domain-anfaellig-3686474.html (ja, der Angriff geht seit 19. April zumindest bei Chrome ins Leeren; er hat aber 15 Jahre lang gut funktioniert...)

Wenn dann plötzlich als Zertifikat-Aussteller anstatt "Symantec Corporation" etwas ganz anderes stehen würde, dann wäre das doch auffällig.

Missverständnis: Da steht mit Sicherheit "Symantec" oder "Verisign" oder "Comodo". Aber eben nicht, wem das Zertifikat eigentlich gehört. Der Postbank AG oder Crime Inc.

Außerdem: Wenn mein Gerät nicht virenversäucht ist, wie soll dann überhaupt jemand, nur weil er im gleichen WLan ist, irgendwelche gefälschten Zertifikate installieren?

Gar nicht. Muss er auch nicht, siehe oben.
Dazu kommt: sslstrip funktioniert leider immer noch. Auch nach acht Jahren noch... Das Tool zwingt den Browser auf eine unverschlüsselte Verbindung runter. Das könnte dem Anwender zwar auffallen. Aber nur, wenn er in die URL-Zeile schaut.
Techniken wie HSTS helfen da zwar (vereinfacht: der Browser hat eine Liste mit URLs, bei denen er nur TLS-Verbindungen akzeptiert). Nachdem aber nicht jede Seite in der Liste steht (so z.B. die der DKB nicht in der HSTS-Liste von Chrome), bringt das auch nicht flächendeckend etwas.

Ich hoffe, dass es nun klarer ist?

 

[Amino]

Danke für die detaillierte Antwort!

Missverständnis: Da steht mit Sicherheit "Symantec" oder "Verisign" oder "Comodo". Aber eben nicht, wem das Zertifikat eigentlich gehört. Der Postbank AG oder Crime Inc.

Interressant. Also müsste man eigentlich nur (während man auf der Login-Seite ist) nachsehen, ob es sich um ein EV-Zertifikat handelt und ob der Webseitenbesitzer im Zertifikat aufscheint? Und dann ist alles bestens (sofern der Aussteller des Zertifikates vertrauenswürdig ist)?

Oder wäre es vielleicht besser, die IP-Adresse manuell einzutippen? Interessanterweise funktioniert genau das gar nicht, das Zertifikat wird dann als ungültig angezeigt...

 

[Mr. Hard]

Danke Travelling_Geek

Kann ich das beschriebene Szenario dich eine VPN-Verbindung aushebeln?