Ja, da gebe ich dir recht.
Ich denke man muss hier betonen das die User eh verschlüsselte Dienste benutzen sollten.
Der einzige pro Punkt für die Verschlüsselung wäre das es kein Datenmaipulation auf dem Weg vom Supernode zum Node erfolgen kann.
Es geht doch nicht um den Freifunk Nutzer, sondern um den Knotenaufsteller der Internet spendet. Wenn der sich in Sicherheit gewogen gefühlt hat, das zwischen dem Freifunk Knoten und dem Gateway/Supernode ein Verschlüsselter Tunnel besteht, dann darf man ihm dieses nicht einfach weg nehmen.
Mir sind die Vektoren bekannt auf die ein Angriff auf das Netz erfolgen kann. Es geht mir aber nur um die einzige Verbindung zwischen Anschluss des Internet Spenders und dem Gateway/Supernode. Und die ist bei den meisten Communitys halt verschlüsselt und viele grafische Darstellungen in Flyern und Powerpoint Slides geben genau diese Situation wieder. So steht in vielen Anleitung der Rheinland Communitys folgendes:
MESH-VPN AKTIVIEREN:
Hiermit erlaubst Du deinem Freifunk-Router über deinen Internetanschluss eine verschlüsselte Verbindung zu den Supernodes Deiner Community herzustellen.
Der Begriff VPN steht für den unbedarften Menschen das es sich um verschlüsselte Verbindungen handelt. Weicht diese Prinzip nicht auf für ein paar MBit mehr. Wir machen uns sonst nur unglaubwürdig.
4 „Gefällt mir“
Im Moment ist es noch ein technischer Test - wenn das klappt und ausgerollt wird, müssen wir natürlich schauen, was hier zu tun ist. Optional eine Verschlüsselungsschicht drauf? Kommunikation ändern?
Unter VPN versteht der unbedarfte Mensch ungestraft Torrents machen. Das ist bei uns ja schon fast irreführende Werbung. 
1 „Gefällt mir“
Unter VPN verstehen die meisten vermutlich, dass sie ohne zusätzliche Lizenzen Spiele gemeinsam spielen können oder auf Youtube Videos ohne GEMA-Sperre schauen.
Ich denke, dass wenn wir unverschlüsselte Tunnel einführen, sie stark bewerben sollten und zumindest übergangsweise noch wahlweise zu verschlüsselten anbieten. Der Config-Mode könnte dazu eine kurze Erklärung liefern.
2 „Gefällt mir“
Aus meiner Sicht ist das ein sehr kritischer Punkt, von dem der Erfolg unseres ganzen Ansatzes abhängt.
In all meinen Gesprächen auf der Suche nach „Anschlussspender“ sind 3 Punkte entscheidend:
- Störerhaftung durch uns - bliebe nach Umstellung weiter erhalten, als Risiko bleibt die Novelle des TMG…
- „Ihr deckt doch Kriminelle“ durch Eure Anonymisierung - die Transparenz ab dem Internetzugang per Supernode bleibt bestehen, somit kann man dies auch zukünftig entkräften.
- Die „Sicherheit“ meines Netzwerkes bzw. meiner Geräte - Wenn wir die Verschlüsselung (VPN-Tunnel) der Verbindung zwischen Nodes und Supernodes aufweichen bzw. deaktivieren, finde ich kein Argument mehr gegen diese Pflicht…
1 „Gefällt mir“
Hi Frank,
Die „Sicherheit“ meines Netzwerkes bzw. meiner Geräte - Wenn wir die Verschlüsselung (VPN-Tunnel) der Verbindung zwischen Nodes und Supernodes aufweichen bzw. deaktivieren, finde ich kein Argument mehr gegen diese Pflicht…
Die Verschlüsselung hat keinen Einfluss auf die Hardware zuhause. Nur weil die Daten unverschlüsselt übertragen werden ist dadurch keinerlei Zugriff auf die lokale Hardware möglich.
Die Daten sind ja weiterhin enkapsuliert 
Die Sicherheit des Freifunk Nodes selbst ist nicht schlechter als zuvor, wie ich schon im ursprünglichen Thread beschrieben habe. Das Mesh Netzwerk ist öffentlich zugänglich, dadurch muss dieses immer als unsicher angesehen werden. Daher empfehlen wir z.b. auch generell die Nutzung von sicheren Protokollen wie TLS wenn man im Freifunk Netz unterwegs ist. Gleiches gilt für Hotspots von der Telekom, dort kann auch Traffic mitgeschnitten werden.
Von daher sehe ich Punkt 3 auch als erfüllt an
3 „Gefällt mir“
Hi CyrusFox,
danke Dir für die Klarstellung, Zustimmung.
Die „Kapsel“ um die Daten (Tunnel) ist entscheidend, nicht so sehr die Verschlüsselung (Nur dann, wenn die gesamte Strecke verschlüsselt ist).
Würde sich nicht PPTP anbieten?
Klar, das Ding ist halt genau so unsicher wie MSCHAP2.
Aber hey… für unsere Anwendung würde es vollkommen reichen. Wer wirklich an die Daten will, dass er CPU-Kraft und Replays fahren will, der könnte dann auch den Traffic anders abgreifen „für weniger Geld“.
Und PPTP ist leichtfüßig.
1 „Gefällt mir“
Pptp funktioniert leider in unserem Fall nicht da es ein Layer 3 Protokoll ist. Außerdem nutzt es GRE Tunnel welche nicht mit NAT funktionieren.
Daher können wir dies nicht verwenden.
Man könnte allerdings HMAC Auth für Tunneldigger umsetzen. Das hatten wir im IRC angesprochen.
Damit hätte man dann aber doch ein Transit-Netz mit statischen IP-Adressen für L2TP.
NAT-Traversal bei mehreren PPTP-Clients hinter einem Zwangsrouter ist natürlich ein Problem.
Damit hätte man dann aber doch ein Transit-Netz mit statischen IP-Adressen für L2TP.
Das schon, aber dann wäre das Filesystem voll 
PPTP benötigt z.b. PPP und noch ein paar andere Dinge.
Da ist einfach kein Platz für da und es wäre eine doppelte Kapselung, bei manchen Anschlüssen würde dann Alfred und Ipv6 gar nicht mehr klappen da die minimum MTU dafür 1280 ist.
NAT-Traversal bei mehreren PPTP-Clients hinter einem Zwangsrouter ist natürlich ein Problem.
Richtig. Aber bei Unitymedia würde es z.b. gar nicht mehr klappen da durch das Carrier-Grade NAT gar kein GRE geht.
Außerdem muss die Firewall bei den Usern zuhause GRE unterstützen. Speedports, Fritzboxen und dergleichen können dies nicht.
[quote=„CyrusFox, post:11, topic:8539“]
Außerdem muss die Firewall bei den Usern zuhause GRE unterstützen. Speedports, Fritzboxen und dergleichen können dies nicht.[/quote]
Fritten können das, die können GRE an einen Host weiterleiten. Zumindest lt. WebUI (FritzOS 6.20); not tried myself, yet.
@CyrusFox: Der Grund, L2TP statt GRETAP einzusetzen, liegt also in der NAT-Fähigkeit von L2TP?
L2TP funktioniert einwandfrei, nur PPTP nicht.