SSL in VPN ist sicherererer ...

peterle

peterle

Forenkasper
Wir hängen uns in irgendein öffentliches WLAN und verbinden unseren Browser mit einem Webserver.
Dann schicken wir sensible Daten hin- und her.

Im einfachsten Fall ohne jede Verschlüsselung der Leitung kann jeder die einzelnen Pakte aus dem WLAN fischen und ggf. verwerten.

Also schalten wir auf dem Webserver auf ssl um, können die Pakete nicht mehr so ohne weiteres verwertet werden, es sein denn, jemand gelangt an den Schlüssel der Verbindung.

Jetzt bauen wir ein VPN und verbinden uns vom VPN-Client zum VPN-Server und von da aus zur Webseite per ssl, was meiner Meinung nach nur das Problem vom ersten Teil in einen zweiten Teil der Verbindung verlagert.

Andere Variante, wir hängen den Webserver in ein VPN und benutzen weiterhin SSL für die Verbidnung zum Webserver, aber ich frage mich, ob das irgendeinen sittlichen Nährwert bei der Sicherheit hat, außer bei einem Fehler einer Verschlüsselung noch eine Wand stehen zu haben.

Sobald wir einen man-in-the-middle haben, haben wir das Speil eh verloren - nehme ich mal an.

Habe ich irgendwelche Denkfehler dabei?
Danke. :)
 
Der einfachste Fall: ja bloss wie wahrscheinlich ist es das gerade jetzt jemand in dem öffentlichen WLAN rum spukt und deine Pakete fischt... würde mal sagen im Cafe gegenüber relativ unwahrscheinlich in nem Flughafen wesentlich wahrscheinlicher.
Wesentlich unwahrscheinlicher ist, das der Angreifer an den session key bei einer ssl Verbindung gelangt. Dafür gibt es ja den Handshake... Allgemein sollte man aber solche dauerhaften Sachen in öffentlichen WLANs eh vermeiden...
Von VPN zu SSL Server... in der Regel erhält man bei einem VPN andere Verbindungspunkte zum Internet. Deshalb ja auch die Möglichkeit Videos an zu gucken die in Deutschland ggf gesperrt sind. Die Verschlüsselung ist stärker und arbeitet auf andern TCP Ports. Da müsste dann schon jemand direkt am Empfänger alles mitschneiden um an deine Sensiblen Daten zu kommen.
Wenn der Webserver im VPN hängt, ist die frage... wie vertrauenswürdig sind die Mitbenutzer. Für ein VPN wie VyprVPN oder ein anderer unter den grossen würde ich sagen nicht sehr... In einem Firmen VPN sollte es da schon überschaubarer sein. Was nicht heissen soll, das man alles an Sicherheit ausser acht lassen sollte wenn man einen Intranetserver betreibt, das einzige wo so ein Konstrukt überhaupt Sinn macht, Gelegenheit macht Diebe.

Für öffentliche WLANs: Starkes SSH Passwort (einer meiner Server wird seit Tagen mit sinnlosen Wörterbuch-Attacken angegriffen ... http://pastebin.com/gVHzTtvs hier mal ne liste mit welchen Benutzer Namen die es probieren) oder Ports am besten ganz zu. Und Sessions allgemein kurz halten ggf auch ein Filter aufs Display damit ein Angreifer nicht sieht auf welchen Seiten man gerade SSL Verbindungen offen hat. Paranoia kann man unendlich treiben... ich z.B. bin nur äusserst selten in öffentlich WLANs ... mein Mobile Volumen reicht ne Weile und as alles gilt aber eh nur für eigene Rechner... ich bin das so einer der meint, "wer einen öffentlichen Terminal verwendet und dort ohne Not sensible Daten eingibt gehört schon fast beklaut".
 
@peterle Du hast wahrscheinlich hinter dem Einen und dem Anderen OpenSSL. Was wichtiger ist ist darauf zu schauen, dass dein HTTPS gut konfiguriert ist.

Ein Szenario wo das mit dem VPN theoretisch helfen könnte ist, wenn jemand tatsächlich versucht mit einem gefälschten Zertifikat dazwischenzufunken. Dagegen könntest du dich absichern wenn du irgendeine Art von Key Pinning macht, bzw. eben dafür sorgst, dass der Fingerprint überprüft wird.

Was ich meine ist, wenn jemand einen bösen CA hat oder irgendeinen CA, dem du vertraust kompromittiert und außerdem eine Attacke auf DNS fährt (dagegen kannst du dir DNSCrypt ansehen).

Und zuletzt noch eine Frage. Ich nehme an du meintest Pakete im Sinne von TCP und nicht FreeBSD-Packages? Falls doch und falls dein Webserver lediglich dazu dient FreeBSD-Packages auszuliefern, dann kannst du in poudriere oder was du verwendest einfach Signaturen anschalten. Wenn du dann den Key in pkg konfigurierst, dann könnte zusätzliche Verschlüsselung nur noch versuchen zu verhindern, dass jemand weiß was genau du installierst. Darauf würde ich mich aber dann keinesfalls verlassen, weil auch ein passiver Angreifer allein schon was den Traffic und die ungefähre Größe der Pakete angeht sicherlich sehr gut darin wäre zu erraten was für Pakete du installierst. Allerdings möchte ich mal davon ausgehen, dass das eher nicht die Art von Angriff ist vor der die Meisten hier Angst hätten.
 
@Athaba

Es waren TCP-Pakete gemeint.
Der Serverzugang gehört eigentlich in ein Intranet und ich persönlich bevorzuge hier zur Sicherheit erst mal ein VPN und als Opensourcefreund natürlich OpenVPN.
Ich ziehe das VPN vor, weil ich keinen Sinn drin sehe, etwas zu zeigen, was erst mal keinen was angeht.

Mir hat nur neulich einer ein Angebot gemacht, der meinte es wäre sicherer, wenn man erst eine SSL-Verbindung zu ihm baut und er dann per SSL-zum Server geht. Jetzt will er den ersten Teil mit einem VPN machen. Er will viel Geld für diese geniale Idee und ich pack mir an den Kopf, frage mich aber, ob ich was übersehen habe - habe ich aber scheinbar nicht.
 
Ein klarer Vorteil von VPN ist: Weder der Wlan-Betreiber noch irgendwelche Leute, die vorort mitlesen, können erkennen, wohin Du surfst. Sie sehen nur die VPN-Verbindung, aber eben nicht, welchen Webserver Du per SSL ansprichst.
 
Wenn Du einen eigenen (V)Server mit SSH-Zugang hast, könntest Du auch durch den SSH-Tunnel per socks5-proxy surfen. Dann bist Du auch im offenen WLAN sicher und surfst mit der IP deines Servers. Im Firefox ist das einfach zu realisieren. Mit Chrome habe ich das noch nicht probiert, sollte aber vermutlich genauso funktionieren. So mache ich das, wenn ich unterwegs im Hotel bin.
 
Ich hab statt VPN auf den (Windows 10, Linux, FreeBSD) Laptops und den Androiden einfach einen stunnel im Client Modus laufen, Zuhause auf dem Router/Server einen stunnel im Server Modus. Durch den wird eine Socks 5 Verbindung zum Server getunnelt. Die stunnel Clients und der Server authentifizieren sich gegenseitig über Zertifikate. Den stunnel kann man im Gegensatz zu VPN ganz einfach permanent laufen lassen, es besteht keine ständige Verbindung.

Firefox kann man einfach in about:config auf den lokalen Socks5 Proxy setzen, geht auf allen Systemen. Bei Chrome/Chromium geht es nur über Startparameter, daher bei Android leider nicht (oder weiss jemand wie das da geht?). WICHTIG: Nicht vergessen, die DNS Anfragen auch über den Proxy zu leiten!

Die ganz paranoiden (also ich z.B. ;) ) lassen ausserdem einen lokalen validierenden Resolver laufen (geht unter Windows 10, Linux, FreeBSD und Android), dann kann auch kein krimineller WLAN Betreiber das DNS umbiegen. Zumindest nicht bei DNSSEC geschützten Domains (also meinen eigenen z.B., wo der stunnel drauf läuft).
 
Rosendoktor schrieb:
WICHTIG: Nicht vergessen, die DNS Anfragen auch über den Proxy zu leiten!
Zum Vergrößern anklicken....

So funktioniert SOCKS5 nicht. Man leitet nicht DNS über den Proxy, sondern der Client macht einfach keine lokalen Lookups und übergibt dem Proxy direkt Hostnamen statt IP-Adressen. Im Prinzip müsste man DNS in der resolv.conf komplett stillegen.
 
TCM schrieb:
So funktioniert SOCKS5 nicht. Man leitet nicht DNS über den Proxy, sondern der Client macht einfach keine lokalen Lookups und übergibt dem Proxy direkt Hostnamen statt IP-Adressen. Im Prinzip müsste man DNS in der resolv.conf komplett stillegen.
Zum Vergrößern anklicken....

Unter Firefox kann man das per 'about:config' einstellen, indem man 'network.proxy.socks_remote_dns' auf 'true' setzt.
 
Und für Chrome/Chromium z.B.:

Code: 
chrome --proxy-server="socks5://localhost:1080" --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE localhost"  %U
 
peterle schrieb:
Nach fünf Fehlversuchen muß man bei mir lange warten. Warum blockst Du die nicht?

Danke für die ausführliche Meinung.
Zum Vergrößern anklicken....
Blocken ist so ein zweischneidiges Schwert... das verleitet zum wechseln der IPs dann kann man nicht mehr sehen welche Angriffe zusammen gehören. Mach ich aber vielleicht noch, nur um zu testen/lernen wie das mit den Scripten bei Splunk funktioniert (leider ist meine Devlizenz grad abgelaufen, hoffentlich krieg ich demnächst ne neue).
Das mit den nach 5 Fehlversuchen muss man länger warten kann ein problem darstellen, wenn man dann ggf selbst länger warten muss.
Bei dem Server ist PermitRootLogin auf no, AllowEmptyPasswords auch auf no und Nur ein User der ein Passwort hat. Und der ist noch kein einziges mal angegriffen worden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben