Aber spielt es eine Rolle, ob man sich per W-LAN dor tanmeldet oder per LAN bzw. per W-LAN oder LAN absnifft? Normal nicht, oder?
Nein, LAN/WLAN ist Layer 1 oder vllt noch Layer 2 (Schicht: Netzzugang). HTTP ist mit Layer 5 und 7 (Anwendungsschicht) zig Abstraktionsebenen höher angesiedelt. Wie die Daten übertragen werden, weiß die Anwendungsschicht nicht. Selbst wenn Layer 1/ 2 eine Brieftauben-Übertragung ist, interessiert das auf Anwendungsschicht nicht mehr.
Wieso konnte ich dann aber, als ich mich mi teinem W-LAN Gerät eingeloogt habe (wir sprechen insg. von zwei Geräten, die ich per DynDNS anspreche) und mit einem PC (per LAN) Wireshark laufen lies, die "GET-Methode" bzw. die Daten nicht sehen? Das verstehe ich nicht-.
Du sprichst die Geräte nicht mit DynDNS an. Das ist Käse. Mit DynDNS hast du dir eine oder zwei Domains registriert und diese zeigen auf das jeweilige Gerät. Aber gut, über die misslungenen Formulierungen sehe ich mal hinweg.
Das kann verschiedene Gründe haben. Entweder hast du das Paket deshalb nicht gesehen, weil du an der falschen Stelle danach gesucht hast oder du konntest es gar nicht sehen. Nehmen wir an, deine Netzwerktopologie sieht so aus:
Geräte: A, B, C, Zielserver Z
[src=text]A -- B -- Z
|
C[/src]
A[eth0] mit B[eth0]
C[eth0] mit B[eth1]
B[eth2] mit Z[eth0]
Wenn du von A zu Z ein Paket sendest, dann kannst du das Paket auf:
- A eth0 als outgoing
- B eth0 als incoming
- B eth2 als outgoing
- Z eth0 als incoming
"erkennen".
An anderen Netzwerkinterfaces oder anderen Geräten (insbesondere C) wirst du das Paket (bei Switches/ Routern im Normalfall) nie zu Gesicht bekommen.
Und: BEIDES ist unsicher. ABER zumindest wäre es doch besser, wenn man es mit der "POST-Methode" übermitteln würde, damit wenigstens nicht im absoluten Klartext alles da steht, oder? Auch wenn das nicht sicher ist, ich weiß.
Nein. Es ist nicht besser und auch nicht schlechter Daten per GET oder POST zu übertragen.
Sie werden (erstmal) so oder so im Paket im Klartext mitgesendet. Bei GET und POST unterscheidet sich nur die Position im Paket, an der sie stehen. GET => die Daten stehen im Header des Pakets, POST => die Daten stehen im Body des Pakets. Das Paket beinhaltet immer einen Header und ggf. einen leeren oder eben einen "gefüllten" Body. Nur weil Wireshark dir den Body nicht direkt anzeigt (das tut es schon, nur eben ein wenig tiefer), heißt das nicht, dass er nicht da ist, aber irgendwo muss man eben auch Übersichtlichkeit bewahren.
Es gibt ein paar Fälle, in denen du GET bevorzugst und ein paar Fälle, in denen du POST verwenden musst.
Beispielsweise hast du bei der Übertragung per GET gewöhnlich kleinere Pakete, wenn du also Traffic sparen willst und es dir auf ms ankommt, willst du lieber GET.
Wenn du größere Datenmengen versenden willst - das passiert bspw bei Bildern oder ähnlichem - dann musst du POST verwenden.
Wenn du nicht möchtest, dass irgendwer mitlesen kann, dann musst du die Daten IMMER verschlüsseln.
Frage: Am bsten ist es per SSL. Was, wenn ein Gerät ein Zertifikat implementiert hat? Also z.B. ein Rack Server oder so. REciht das, damit verschlüsselt wird, oder muss der DynDNS Dienst, über den man sich einloggt, z.B. DynDNS.org, das Zertifikat anbieten bzw. eben die Verbindung verschlüsseln?
Ich glaube dir ist gar nicht klar, wie die Kommunikation im Netzwerk so wirklich abläuft.
Wenn dein Server SSL unterstützt, also sowohl das Protokoll, als auch über ein Zertifikat verfügt und deine Anwendung ebenfalls SSL kann, dann steht einer verschlüsselten Übertragung nichts im Wege.
Dann greifst du per https:// auf deine Ressource zu, anstatt
http://. Dein Browser erkennt dann automatisch, dass du eine sichere Verbindung möchtest und versucht diese mit dem Server auszuhandeln. In Etwa so (TLS Handshake):
Zu dieser Zeit interessiert der Service von DynDNS allerdings nicht mehr wirklich.
DynDNS stellt lediglich ein Mapping von <sub>.dnydns.org auf eine IP, nicht mehr und nicht weniger.
