nicht angemeldet
Frage zu Sicherheit bez. WLAN, UMTS
0 0 0
Frage zu Sicherheit bez. WLAN, UMTS
Hallo, wenn ich in einem Cafe bin und mich mit einem unverschlüsseltem Drahtlosem Netzwerk verbinde, erscheint die Meldung, dass die Daten evtl. für andere Sichtbar sind. Wie soll das denn gehen, könnten die jetzt lesen, was ich hier schreibe? Wie sehr muss man diese Meldung ernst nehmen?
Und wie sieht es mit UMTS aus, könnte man die "Funkwellen" abfangen und z.B. meine Zugangsdaten für Onlinebanking abfangen?
LG
Steffie
-
Hello Steffie,
im Prinzip sollte immer zwischen Server und Client direkt ein Tunnel aufgebaut werden, also eine Verschlüsselung vereinbart werden.
Die Pakete, die über ein WLAN versendet werden oder auch über eine Bus-Struktur übers Kabel, sind von allen anderen Hosts im selben Segement lesbar. Bei WLAN können dementsprechend alle mitlesen.
Natürlich braucht man dafür spezielle Programme, aber die gibt es inzwischen auf diversen Servern im Internet zum Download.
Soweit ich weiß, ist UMTS auch nicht unangreifbar, aber da halte ich mich mit einer verbindlichen Aussage zurück.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Mhh, ok vielen Dank euch beiden. Da ich zuhause mein WLAN verschlüsslet habe, dürfte ich ja zumindest hier auf der sicheren Seite sein. Aber wie sieht das denn aus, wenn man die Daten anderer "mitliest"? Kann man dann sozusagen live sehen, was der gerade schreibt? Und wie heist denn so Software, dann würde ich das mal gerne hier bei, in meinem WLAN ausprobieren.
-
Hello,
Mhh, ok vielen Dank euch beiden. Da ich zuhause mein WLAN verschlüsslet habe, dürfte ich ja zumindest hier auf der sicheren Seite sein. Aber wie sieht das denn aus, wenn man die Daten anderer "mitliest"? Kann man dann sozusagen live sehen, was der gerade schreibt? Und wie heist denn so Software, dann würde ich das mal gerne hier bei, in meinem WLAN ausprobieren.
Na, etwas Forscherdrang müssen wir doch noch lassen :-)
Linuxrechner können das schon von Haus aus.
Du musst allerdings Dein Device auf "Promiscous Mode" umschalten, damit es jedes Paket annimmt nund nciht nur diejenigen, die für Dich bestimmt sind.Versuche es z.B. mal mit Wireshark
Um das nochmal klar zu machen: Es ist nicth der LAN im WLAN verschlüsselt, sondern sozusagen nur das "W". Dadurch kannst Du nicht Mitglied des LANs werden.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
-
Yerf!
Hallo, wenn ich in einem Cafe bin und mich mit einem unverschlüsseltem Drahtlosem Netzwerk verbinde, erscheint die Meldung, dass die Daten evtl. für andere Sichtbar sind. Wie soll das denn gehen, könnten die jetzt lesen, was ich hier schreibe? Wie sehr muss man diese Meldung ernst nehmen?
Ja, man kann ein unverschlüsseltes WLAN über eine speziell eingerichteten WLAN-Adapter recht leicht abhören.
Was aber viele nicht wissen: auch ein verschlüsseltes öffentliches Netz (z.B. Cafe) ist unsicher: jeder Teilnehmer im selben Netz kann die Daten der anderen Teilnehmer abfangen, da er ja den Schlüssel hat und somit alle Daten innerhalb des WLANS unverschlüsselt "sieht".
Und wie sieht es mit UMTS aus, könnte man die "Funkwellen" abfangen und z.B. meine Zugangsdaten für Onlinebanking abfangen?
Über UMTS weis ich recht wenig, gehe aber davon aus, dass die Übertragung verschlüsselt stattfindet. Vor allem aber dürfte jeder Benutzer eine eigene Verbindung haben, womit das Abhören innerhalb des Netzes nicht gehen sollte.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Moin Moin!
Über UMTS weis ich recht wenig, gehe aber davon aus, dass die Übertragung verschlüsselt stattfindet. Vor allem aber dürfte jeder Benutzer eine eigene Verbindung haben, womit das Abhören innerhalb des Netzes nicht gehen sollte.
Niemand hindert einen motivierten Angreifer, eine eigene UMTS-Basisstation zu betreiben, um UMTS-Verbindungen über seine eigenen Systeme laufen zu lassen, genauso wie es einige Leute schon mit GSM-Basisstationen gemacht haben.
Aufwendige Schutzmechanismen (End-zu-End-Verschlüsselung mit Zertifizierung jeder einzelnen UMTS-Basis) gibt es offensichtlich bei UMTS nicht. In der letzten c't 6/2009 wurde ein netter kleiner WLAN-Router mit einer UMTS-Basis (mit minimaler Reichweite) vorgestellt (Netgear DVG834GH), explizit dafür ausgelegt, das UMTS-Spielzeug des Kunden zuhause über DSL ans Internet zu bringen.
Spätestens hinter dem Router habe ich mit einem handelsüblichen Ethernet-Hub und einem PC mit Ethernet-Sniffer ALLE Möglichkeiten, die Daten abzuhören und mit einer weiteren Netzwerkkarte im PC kann ich die Daten auch beliebig manipulieren.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hello,
bei der Gelegenheit möchte ich gleich selber noch eine Frage zu HTTPs nachschieben. Ich habe da beim Kapitel SSL/TLS wohl noch nicht richtig aufgepasst...
Wenn ich aus einem Intnenet-Cafe mit einem Browser zu meinem HTTPs-Dienst aufbaue, der mit Self-Certificate arbeitet, dann stimmen sich Server und Client ab und vereinbaren eine Verschlüsselung.
Ist das jedes Mal derselbe Schlüssel, der Verwendung findet?
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Moin!
Wenn ich aus einem Intnenet-Cafe mit einem Browser zu meinem HTTPs-Dienst aufbaue, der mit Self-Certificate arbeitet, dann stimmen sich Server und Client ab und vereinbaren eine Verschlüsselung.
Der Browser wird aber eine Warnung ausgeben, dass das Zertifikat der Gegenstelle nicht von einer dem Browser bekannten Zertifizierungsstelle unterschrieben wurde. Um also sicherzugehen, dass du wirklich mit deinem Server redest, musst du das Zertifikat manuell auf Korrektheit prüfen (Vergleich des Fingerabdruck-Hashes).
Ist das jedes Mal derselbe Schlüssel, der Verwendung findet?
Nein, die Verschlüsselung wird dynamisch und mit Zufallskomponenten hergestellt. Ausserdem erfolgt sie natürlich in einer Weise, die auch beim Mithören keine Angriffspunkte bietet, um generierte Schlüssel herauszufinden.
- Sven Rautenberg
-
Hello,
Moin!
Wenn ich aus einem Intnenet-Cafe mit einem Browser zu meinem HTTPs-Dienst aufbaue, der mit Self-Certificate arbeitet, dann stimmen sich Server und Client ab und vereinbaren eine Verschlüsselung.
Der Browser wird aber eine Warnung ausgeben, dass das Zertifikat der Gegenstelle nicht von einer dem Browser bekannten Zertifizierungsstelle unterschrieben wurde. Um also sicherzugehen, dass du wirklich mit deinem Server redest, musst du das Zertifikat manuell auf Korrektheit prüfen (Vergleich des Fingerabdruck-Hashes).
Das ist mir schon klar.
Der nächste, der an diesem Host (Client) sitzt, wird aber nicht mehr gefragt, da der sich das Server-Zertifikat gemerkt hat.Ist das jedes Mal derselbe Schlüssel, der Verwendung findet?
Nein, die Verschlüsselung wird dynamisch und mit Zufallskomponenten hergestellt. Ausserdem erfolgt sie natürlich in einer Weise, die auch beim Mithören keine Angriffspunkte bietet, um generierte Schlüssel herauszufinden.
Eben das ist mir noch vollkommen unverständlich. HTTPs ist doch auch zustandslos?!
Dann wird also für jedes Request/Response-Paar ein neuer Schlüssel ausgehandelt?Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Moin!
»» Der Browser wird aber eine Warnung ausgeben, dass das Zertifikat der Gegenstelle nicht von einer dem Browser bekannten Zertifizierungsstelle unterschrieben wurde. Um also sicherzugehen, dass du wirklich mit deinem Server redest, musst du das Zertifikat manuell auf Korrektheit prüfen (Vergleich des Fingerabdruck-Hashes).
Das ist mir schon klar.
Der nächste, der an diesem Host (Client) sitzt, wird aber nicht mehr gefragt, da der sich das Server-Zertifikat gemerkt hat.Nicht unbedingt. Standard dürfte in den meisten Browsern eigentlich sein, so ein Zertifikat nur temporär zu akzeptieren, d.h. für den Zeitraum der Browsersession. Ein Neustart des Browsers (und natürlich des Gesamtsystems) vernichtet jegliche Akzeptanzspuren des Zertifikats.
Wenn du das Zertifikat dauerhaft erlauben willst, musst du das in der Regel aufwendiger bestätigen, als nur "OK" klicken.
»» > Ist das jedes Mal derselbe Schlüssel, der Verwendung findet?
»»
»» Nein, die Verschlüsselung wird dynamisch und mit Zufallskomponenten hergestellt. Ausserdem erfolgt sie natürlich in einer Weise, die auch beim Mithören keine Angriffspunkte bietet, um generierte Schlüssel herauszufinden.Eben das ist mir noch vollkommen unverständlich. HTTPs ist doch auch zustandslos?!
Dann wird also für jedes Request/Response-Paar ein neuer Schlüssel ausgehandelt?Ich kenne im Moment auch keine Details. Allerdings müssen nicht alle Bedingungen, die für HTTP gelten, auch für HTTPS gelten, denn HTTPS ist ja eigentlich "HTTP over SSL", die HTTP-Daten werden einfach nur durch einen SSL-gesicherten Tunnel geschickt. Genauso wird "SMTP over SSL" realisiert, oder "FTP over SSL" (aka FTPS, nicht verwechseln mit SFTP), oder oder oder. Die Herstellung des SSL-Tunnels hat dabei nicht unbedingt etwas mit dem danach verwendeten Protokoll zu tun. Sprich: Es wäre durchaus denkbar, dass Server und Client für den SSL-Part zustandsbasiert agieren, während das dann gesprochene HTTP zustandslos ist.
Allerdings späche auch nichts dagegen, dass HTTPS zustandslos ist - Fakt ist, dass der SSL-Overhead durchaus bemerkbar die Performance drücken kann, und das muss nicht allein am eigentlichen Verschlüsseln liegen.
- Sven Rautenberg
-
Hello,
Der nächste, der an diesem Host (Client) sitzt, wird aber nicht mehr gefragt, da der sich das Server-Zertifikat gemerkt hat.
Nicht unbedingt. Standard dürfte in den meisten Browsern eigentlich sein, so ein Zertifikat nur temporär zu akzeptieren, d.h. für den Zeitraum der Browsersession. Ein Neustart des Browsers (und natürlich des Gesamtsystems) vernichtet jegliche Akzeptanzspuren des Zertifikats.
Ja, stimmt. Da hatte ich wohl gestern beim Üben den Firefox und seine Macken nicht beachtet. Mit dem IE funktioniert es immer einwandfrei. Der Firefox behält das Zertifikat, bis er komplett geschlossen wird, und nicht, bis die letzte Instanz geschlossen wird, die eins davon hält. :-(
Ok, VPN oder SSL sind zustandsorientiert. Dann wäre das also plausibel, dass der Browser den Kanal solange hält, wie es eine Intanz gibt, die ihn benötigt. Das müsste sich ja per Wiresjark o.ä. feststellen lassen. da müssten dann ja Keep-Alive-Pakete (Heartbeat) kommen, auch wenn gerade keine HTTP-Requests laufen. Muss ich mal schauen, ob ich den Versuchsaufbau hinbekomme.
Danke.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Moin!
Ok, VPN oder SSL sind zustandsorientiert.
Habe ich so nicht behauptet. :)
VPN muss es sein, denn eine normale Netzwerkleitung ist es ja auch.
SSL könnte es sein - wie erwähnt, ich habe noch keine Details recherchiert. Zumindest gibt es in der Apache-Konfig Optionen, um SSL-Daten zwischenzuspeichern für schnellere Verbindungen.
Dann wäre das also plausibel, dass der Browser den Kanal solange hält, wie es eine Intanz gibt, die ihn benötigt. Das müsste sich ja per Wiresjark o.ä. feststellen lassen. da müssten dann ja Keep-Alive-Pakete (Heartbeat) kommen, auch wenn gerade keine HTTP-Requests laufen. Muss ich mal schauen, ob ich den Versuchsaufbau hinbekomme.
Nö, Keep-Alive muss nicht kommen. Telnet oder SSH sind ja auch verbindungsorientiert, aber wenn keine Daten zu übertragen sind, und man nicht befürchten muss, dass irgendein NAT die Verbindung vergessen könnte, dann ist ein Heartbeat nicht vorgesehen, die Verbindung bleibt trotzdem bestehen.
Natürlich möchte man bei Applikationen, die die Verbindung nutzen sollen, sichergehen, dass sie im Bedarfsfall auch verfügbar ist, um ansonsten schnell eine Problemmeldung oder gar -lösung zu versuchen. Das hat aber nichts mit der Verbindungsorientierung zu tun.
- Sven Rautenberg
-
Hello,
also wenn DU das noch nicht auswendig weißt, dann schäme ich mich nicht mehr ganz so doll :-)
Scheint also doch mal wichtig zu sein, sich da genauer in die Tiefe zu lesen und zu proben und dann auch hier darüber zu publizieren. Wenn die gesetzwidrige (T-Bum, Bahn, usw.) und die zumindest ges. nicht abgesicherte Überwachtung (Schäubles Schergen) steigt, muss man sich zwangsweise dagegen wehren.
Sonst gehen die Demokratie und Meinungsfreiheit vor die Hunde!
Darüber hinaus gibt es dann natürlich noch Betrachtungen, wie man trotz SSL oder VPN eine Verbindung aushorchen kann. Wie kommt man in einen Strohhalm, ohne ihn zu beschädigen? ...
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
-
-
Hallo,
Eben das ist mir noch vollkommen unverständlich. HTTPs ist doch auch zustandslos?!
Dann wird also für jedes Request/Response-Paar ein neuer Schlüssel ausgehandelt?Das ganze sieht so aus: Erst bauen Browser und Server einen SSL/TLS-"Tunnel" zwischeneinander auf und in diesem werden Schlüssel ausgehandelt. Über diesen Tunnel wird dann (wie über eine normale TCP-Verbindung) HTTP gesprochen. Jetzt hast Du zwei Möglichkeiten:
Wenn HTTP/1.1-Keepalive *nicht* verwendet wird, dann hast Du tatsächlich nur 1 Request / Verbindung, d.h. nach dem Ende des Requests wird die Verbindung abgebaut und für weitere Requests werden neue Verbindungen ausgehandelt (was dann zu neuen Schlüsseln führt).
Wenn HTTP/1.1-Keepalive verwendet wird, dann bleibt die Verbindung für mehrere Requests offen, genau so, wie eine normale TCP-Verbindung für mehrere Requests bei plain HTTP offen bleibt, wenn man Keepalive nutzt. Die Requests sind aber dennoch unabhängig voneinander, obwohl sie über die gleiche Verbindung geschehen (so wie bei normalen TCP-Keepalive-Verbindungen halt auch).
Viele Grüße,
Christian
-
-
-
-
-