[WLANnews] Verschlüsselung

[Daniel Nitzpon]

Lars Scheithauer wrote:
> Interessant wäre das in der Tat, wobei ich das Passwort nicht auslesen 
> würde. Ein "Ihre Verbindung ist leider nicht sicher genug. Weitere 
> Infos..." wird wohl reichen.

würde ich schon. das erschreckt viel besser und macht von sicherheit 
o.ä. her keinen unterschied.

mickey wrote:
 > Also das ist absolut nicht mit dem Pico Peering Agreement vereinbar!

üblicherweise wird ppa so ausgelegt, dass es sich auf den peer traffic, 
also die netzinterne weiterleitung bezieht. weder auf gateways noch auf 
den traffic zwischen client und node, was die sinnigsten ansatzstellen 
hierfür wären. sonst wäre auch dhcp-splash ein ppa-verstoß. auch 
"gefühlsmäßig" sehe ich kein problem, jedenfalls dann nicht, wenn es 
eine freischaltoption gibt. es geht ja nicht darum, irgend etwas 
auszusperren was einem nicht gefällt, wie bei filesharing. sondern es 
geht nur darum, leute auf etwas für sie selbst gefährliches hinzuweisen, 
was ihnen wahrscheinlich nicht bewusst ist. ich glaube kaum, dass es 
viele leute gibt, die aus überzeugung ihre passwörter durch den kiez 
schreien oder die technisch keine alternative haben.

 > Lars Scheithauer schrieb:
> Eine simple, portbasierte Implementation wäre ja ohne großen Aufwand 
> machbar, indem man schlichtweg alle Anfragen auf diese Ports umleitet 
> auf einen Server, der dann den Loginprozess (so es denn einen gibt) 
> positiv beantwortet und dann eine entsprechende Fehlermeldung 
> zurücksendet. Hat natürlich den Nachteil, dass (a) mailserver, die nicht 
> auf den standardports liegen nicht erfasst werden und (b) möglicherweise 
> doch verschlüsselte Verbindungen (auf den standardports) ins Leere laufen.

jupp, wenn ich meinen thunderbird glauben darf, liegen z.b. 
unverschlüsselt und tls bei imap beide auf port 143. hielte ich also für 
keine gute idee.

> Um das zu umgehen könnte man also entweder eine MAC-Tabelle aufbauen, 
> wer die Nachricht schonmal bekommen hat, damit die Nachricht nur einmal 
> verschickt wird.

ist evtl. eine gute idee, würde ich aber nur gegen anklicken eines "nerv 
mich nicht, mir egal"-kästchens machen. hat aber das problem, dass es 
vermutlich nach jedem reset/firmwareupgrade/clientumbuchung neu geklickt 
werden muss > nicht so richtig elegant

> Oder man geht auf OSI-Ebene 4 hoch und benutzt Snort o.Ä., um die 
> unverschlüsselten Verbindungen zu erkennen, die Verbindung zu übernehmen 
> / zu reseten und dann die entsprechende Infomail zurückliefert. 

beides in kombination wäre klasse. wenn nur auf mailports geprüft wird, 
frisst das dann so viel ressourcen?

> Wobei man sich natürlich auch die Frage stellen muss, ob sich der 
> Aufwand wirklich lohnt. Schließlich ist FreiFunk ja doch eher eine 
> Geek-community (soweit ich das mitbekommen habe), deren Clients entweder 
> selbst geeks sind oder sowieso einen Geek brauchen, um es einzurichten. ;)

also ich kenne genug leute, bei denen der besuch mal einen rechner 
anstöpselt o.ä. ich glaube, da gehen nennenswert klartext-passwörter rüber.
auch ich hatte anfangs ganz schön schwierigkeitenm zu kapieren, was die 
einzelnen thunderbird-einstellungen wirklich bedeuten...

>> für webmail und ähnliches, wo ggf. passwörter und persönliche daten
>> unverschlüsselt durch die luft fliegen wirds schwierig, weil
>> wahrscheinlich entweder eine umfassende datenbank sensibler seiten
>> gebraucht würde oder ein verschlüsselter tunnel zum gateway, was beides
>> nicht zu leisten sein wird (im 1. fall von den leuten nicht, im 2. von
>> den routern)

fällt dazu jemand noch was ein? wie man dabei layer 8 auf unteren 
protokollebenen unterstützen kann oder so?

> Wie aktiv ist denn momentan noch die Community? Wird immer noch das 
> original OLSR als Protokoll eingesetzt oder mittlerweile BATMAN[1|2] ?

z.zt. beides parallel. batman eher noch im testbetrieb aber durchaus 
funktionsfähig. und an olsr sind auch noch größere umbauten im gange.