headers
Lars Scheithauer | 2 Oct 11:44

Freifunk Map / Verschlüsselung

HiHo, allesamt!

Ich bin neu auf der Liste und hätte 2 kurze Anfragen:

Zum einen wollte ich wissen, ob es schon irgendeine zentrale  
Anlaufstelle für Interessierte am Webmaps-Projekt[1] gibt. Ich habe  
bisher das layer8-Projekt gesehen und Freimap (welches allerdings  
nicht webbasiert ist), wäre aber eher an einer Googlemaps- 
Implementation interessiert. Die letzten Infos habe ich von Mitte  
2006 gefunden. Ich würde da mitmachen oder auch was Neues starten,  
will aber natürlich keine doppelte Arbeit machen. Ist momentan jemand  
für das Freikartensystem verantwortlich?

Als zweites wollte ich kurz eine Frage zum Thema Verschlüsselung  
stellen. Soweit ich das rausgelesen habe, benutzt Freifunk keine  
Verschlüsselung, um das Netz offen zu gestalten. Das birgt allerdings  
diverse (bekannte) Risiken, weil das Netzwerk ja relativ klein ist.  
Nach dem veröffentlichten Forschungsbericht über TOR[2] wäre es da  
wohl nötig, ein paar Überlegungen anzustellen. Gibt es dazu schon  
eine zentrale Anlaufstelle (aka Wiki)?

Grüße aus Heidelberg,
Lars

___________________________________________________________
[1] http://blog.freifunk.net/tags/map
[2] http://www.heise.de/newsticker/meldung/95770/from/rss09
_______________________________________________
WLANnews mailing list
WLANnews@...
(Continue reading)

Permalink | Reply | 6 comments |
headers
Daniel Nitzpon | 2 Oct 12:25
Picon

Verschlüsselung

Lars Scheithauer wrote:
> Als zweites wollte ich kurz eine Frage zum Thema Verschlüsselung 
> stellen. Soweit ich das rausgelesen habe, benutzt Freifunk keine 
> Verschlüsselung, um das Netz offen zu gestalten. Das birgt allerdings 
> diverse (bekannte) Risiken, weil das Netzwerk ja relativ klein ist. Nach 
> dem veröffentlichten Forschungsbericht über TOR[2] wäre es da wohl 
> nötig, ein paar Überlegungen anzustellen. Gibt es dazu schon eine 
> zentrale Anlaufstelle (aka Wiki)?

was meinst du genau? für den nutzer ist die sache ja recht klar und 
einfach: alles irgendwie sensible braucht ende-zu-ende-verschlüsselung.

aus netzbau- und servicesicht fallen mir zwei sachen ein: zum einen die 
admin-passwörter, das ist mit der wifi-login verhinderung zwar gelöst, 
aber nur unbefriedigend, weil nicht ganz dau-kompatibel, aber https ist 
ja auch in arbeit.

zweiter und wesentlicherer punkt sind pop/imap/smtp-verbindungen der 
nutzer. da habe ich mal ideen gehört, die unverschlüsselten abrufe 
abzufangen und eine generierte fakemail zurückzusenden "dein passwort 
ist blabla, wie du sicher auf deine mails zugreifen kannst erfährst du 
unter diesem link", was ich für eine klasse idee (auch für tor-exit 
nodes im übrigen) halte. das das konkret entwickelt würde, habe ich aber 
nie gehört und habe selber leider zu wenig ahnung, um das anzufangen.

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Lars Scheithauer | 2 Oct 13:14

Re: Verschlüsselung

Am 02.10.2007 um 12:25 schrieb Daniel Nitzpon:

> Lars Scheithauer wrote:
>> Als zweites wollte ich kurz eine Frage zum Thema Verschlüsselung
>> stellen. Soweit ich das rausgelesen habe, benutzt Freifunk keine
>> Verschlüsselung, um das Netz offen zu gestalten. Das birgt allerdings
>> diverse (bekannte) Risiken, weil das Netzwerk ja relativ klein  
>> ist. Nach
>> dem veröffentlichten Forschungsbericht über TOR[2] wäre es da wohl
>> nötig, ein paar Überlegungen anzustellen. Gibt es dazu schon eine
>> zentrale Anlaufstelle (aka Wiki)?
>
> was meinst du genau? für den nutzer ist die sache ja recht klar und
> einfach: alles irgendwie sensible braucht ende-zu-ende- 
> verschlüsselung.
>
> aus netzbau- und servicesicht fallen mir zwei sachen ein: zum einen  
> die
> admin-passwörter, das ist mit der wifi-login verhinderung zwar gelöst,
> aber nur unbefriedigend, weil nicht ganz dau-kompatibel, aber https  
> ist
> ja auch in arbeit.

Das beispielsweise wusste ich noch nicht.

> zweiter und wesentlicherer punkt sind pop/imap/smtp-verbindungen der
> nutzer. da habe ich mal ideen gehört, die unverschlüsselten abrufe
> abzufangen und eine generierte fakemail zurückzusenden "dein passwort
> ist blabla, wie du sicher auf deine mails zugreifen kannst erfährst du
> unter diesem link", was ich für eine klasse idee (auch für tor-exit
(Continue reading)

Permalink | Reply | 1 comment |
headers
mickey | 2 Oct 13:31
Gravatar

Re: Verschlüsselung


Lars Scheithauer schrieb:
>> zweiter und wesentlicherer punkt sind pop/imap/smtp-verbindungen der
>> nutzer. da habe ich mal ideen gehört, die unverschlüsselten abrufe
>> abzufangen [...]
> 
> Interessant wäre das in der Tat [...]
> 
> Eine simple, portbasierte Implementation wäre ja ohne großen Aufwand  
> machbar, indem man schlichtweg alle Anfragen auf diese Ports umleitet  
> [...]

Also das ist absolut nicht mit dem Pico Peering Agreement vereinbar!

"1. Freier Transit

    * Der Eigentümer bestätigt, freien Transit über seine freie
Netzwerkinfrastruktur anzubieten
    * Der Eigentümer bestätigt, die Daten, die seine freie
Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen noch
zu verändern."

http://www.picopeer.net/PPA-de.html

--

-- 
mickey@...
gpg key 0xE1B31D88


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Daniel Nitzpon
 | 
2 Oct 15:38






Picon





Re: Verschlüsselung


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 

(Continue reading)






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Lars Scheithauer
 | 
2 Oct 16:19





Re:  Verschlüsselung (und mehr Fragen)


> 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.

Naja, das PPA ist da eigentlich recht deutlich... Außerdem ist das  
Beobachten (auch automatisch) von Netzwerkverkehr in Deutschland  
rechtlich sehr stark eingeschränkt und ich denke nicht, dass man für  
die paar Leute tatsächlich so einen Aufwand betreiben muss - und sich  
zudem noch in eine Grauzone begibt. Von daher würde ich die Sache  
vergessen.

>>> 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

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Daniel Nitzpon
 | 
2 Oct 16:43






Picon





Re: 	Verschlüsselung (und mehr Fragen)


eigentlich dachte ich, zu den meisten sachen stehen genug infos im netz 
und in archiven, sind die so unklar/schwer zu finden?

also kurz im schnelldurchlauf:

Lars Scheithauer wrote:
> Naja, das PPA ist da eigentlich recht deutlich... Außerdem ist das 
> Beobachten (auch automatisch) von Netzwerkverkehr in Deutschland 
> rechtlich sehr stark eingeschränkt und ich denke nicht, dass man für die 
> paar Leute tatsächlich so einen Aufwand betreiben muss - und sich zudem 
> noch in eine Grauzone begibt. Von daher würde ich die Sache vergessen.

das ppa bezieht sich nicht darauf. wirklich ;-)
rechtlich weiss ich nicht genau, würde ich aber auch nicht pauschal 
überzeugt sein, dass es dort probleme gibt, ohne das genauer anzuschauen.

> geeignet hält, Node Y zu erreichen. Dieses Node (off-optic: ist Node 
> eigentlich männlich, weiblich oder sächlich? ;) ) 

sächlich auf keinen fall :-)

> Frage ist jetzt, ob sich jede Node eine Sequenznummer o.Ä. merkt, um 
> eine (für den Augenblick) stateful Route aufzubauen (z.B. für die 
> Antwort von Node Y an Node X), oder ist die Route komplett stateless 

die route (bzw. der nachbar, bei dem diese beginnt) wird ständig neu 
berechnet, aber diese berechnung durchaus dauerhaft (stateful) vorgehalten.

> (d.h. dass die ganze Prozedur für die Antwort von Node Y an Node X 
> wiederholt wird)?

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Marek Lindner
 | 
2 Oct 16:52






Picon

Favicon





Re: 	Verschlüsselung (und mehr Fragen)



Hi,

> Trotzdem ein paar Fragen.

ich denke diese Fragen machen sich auf der batman Mailingliste deutlich 
besser: https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n

Kleine Randbemerkung meinerseits: TLS Verschlüsselung wurde _ausdrücklich_ 
dafür entwickelt, dass man eine unverschlüsselte Verbindung aufbaut, um dann 
auf Verschlüsselung umzuschalten. Wer von unterschiedlichen Ports (80 <> 443) 
redet, meint SSL und nicht TLS. Siehe dazu dieses Beispiel: 
http://tools.ietf.org/html/rfc2817

Gruß,
Marek
_______________________________________________
WLANnews mailing list
WLANnews@...
Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlannews

Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Lars Scheithauer
 | 
2 Oct 17:01





Re:  Verschlüsselung (und mehr Fragen)



> ich weiss nicht, was du genau unter einer ad-hoc-verbindung verstehst.
> alle befinden sich im selben netz und schicken dort ständig sowohl
> broadcasts für die routenfindung als auch unicasts für den  
> datentransfer.

Hab da anscheinend wirklich was falsch verstanden. Ich hatte im Kopf,  
das Ad-Hoc-Netzwerk nur genau einen bidirektionalen Datenkanal  
bereitstellen (also wie ein Nullmodemkabel). duh...

Danke für die schnelle Beantwortung der Fragen!
_______________________________________________
WLANnews mailing list
WLANnews@...
Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlannews

Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Sven-Ola Tuecke
 | 
3 Oct 07:17






Picon





Re: Verschlüsselung


Moins,

alle regen sich immer ueber unsicheres Wifi auf. Das ist genau so unsicher
wie z.B. die Verbindungen zwischen Alice / Supermann / Tele[...] und dem
CIX. Die Carrier verschluesseln auch nicht untereinander AFAIK (waer' echt
unpraktisch und braechte nix), man muesste also nur an geeigneter Stelle
graben.

Das kleine Programm heisst "fakepop" (ipkg install fakepop). Es reagiert auf
einfache POP3-Abfragen und kostet praktisch keine Ressourcen. Ich wuerde es
nur auf einem Inet-Gateway einsetzen wollen. Ein kleines Port-Redirekt
(sagen wir mal 111 -> 110) kann man ja zusaetzlich machen. In der Rueckmail
stuende dann sowas: "Oeffne Konfig-Dialog und stelle Port auf 111 dann geht
auch das unsichere POP3". So eine Minimalhuerde halte ich fuer OK im Sinne
des PP - wenns auf den Gateways verbleibt. Im Regelfall ist es wohl
wirklich "bin zu Faul mich damit zu beschaeftigen".

Bei Webmailern isses uebrigens aehnlich. Bei GMX hilft mir da folgender
Trick: Proxy fuer http auf "localhost:8080" (https Einstellung leer lassen)
und dann https://www.gmx.net/ . Nach dem Login versucht GMX sie ein
Redirekt auf http, da muss man zu Fuss das "s" ergaenzen und weiter
gehts. "http-Proxy-geht nicht" schuetzt auch vor zuviel Reklame <ggg> Ebay
kann leider gar kein https.

Und ja: Jeder Gatewaybetreiber kann ja einen openvpn server aufsetzen. Gibt
fuer Windows ein wirkliche schoenes und DAU-kompatibles
Openvpn-Einwaehldingsbumms. Dann isses wenigsten etwas sicherer bis dahin
(dahinter lauert aber immer noch der IM).

// Sven-Ola

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane