[Freifunk Franken] Das Internet ist kein Rechtfreier Raum

Di Nov 17 19:48:55 CET 2015

Am Dienstag, den 17.11.2015, 19:33 +0100 schrieb Peter J. Philipp:
> 
> On 11/17/15 17:36, Christian Dresel wrote:
> > hi
> >
> > Für den Anwender ist es echt wurscht, der funkt in einen offenen
> > (unverschlüsselten) WLAN rum da ist das mitlesen wesentlich einfacher
> > als im fastd-Tunnel ;) Also hier muss wirklich der Endanwender eine
> > EndtoEnd Verschlüsselung verwenden, wenn ihn seine Daten wichtig sind
> > (wenn er nur ein paar Pornos wie ""Maika bläst das Würstchen" guckt,
> > ists wohl eher wurscht ;))
> >
> > Wenn man allerdings ein wenig weiter überlegt ist es für den
> > Knotenbetreiber nicht ganz so wurscht, falls wirklich jemand
> > "dazwischen" hängt und den Traffic im fastd Tunnel mitschneidet hat er
> > die IP des Knotenbetreibers, irgendwie unschön... Da landet man
> > irgendwann wieder bei der Störerhaftung (oder verstehe ich hier
> > irgendwas noch falsch?!).
> >
> > Interessant ist Peter's Ausführung mit der "kryptographische Summe gegen
> > MITM" was ist damit gemeint? Verhindert dies nun das mitschneiden
> > zwischen Knotenbetreiber und Gateway (MITM)? So genau hab ich mich mit
> > fastd noch nicht beschäftigt, es läuft halt gut (und was gut läuft,
> > fasst man/ich nie an ;) ).
> 
> Soweit ich den code verstanden habe tun alte fastd's eine SHA-1 HMAC
> prüfsumme anhängen
> und neue eine SHA-2 HMAC prüfsumme.  Das heist dann wenn niemand den
> schlüssel zu den
> HMAC's kennt können Die nicht Pakete im Transit ändern, also eine aktive
> MITM oder (mice in the middle) attacke.  Lesen können die das schon was
> passiv ist.  Ich habe nie versucht zu sehen ob die Tunnel server
> wirklich die prüfsumme checken, wäre schade wenn nicht.  Aber es ist
> davon auszugehen das die wirklich geprüft werden.

Wozu mittels HMAC vor MITM, wenn man sich einfach als Server / Client
ausgeben kann und stumpf dazwischen parken kann? Dein Client würde mit
dem MITM Server wunderbar HMAC abgesichert sprechen und der Server mit
dem MITM Client.

Diese ganze Verschlüsselung würde nur was bringen, wenn du die
Schlüssel / Fingerprints auch gegenseitig über einen sicheren Kanal
prüfen würdest. Bei uns sollen die Leute aber alle möglichst einfach
mitmachen können, ein vorheriger Schlüsseltausch wurde von allen bisher
immer strikt abgelehnt.

Tim

> Grüsse aus Schweinfurt,
> 
> -peter
> 
> 
> 
> 
> > mfg
> >
> > Chris
> >
> > Am 17.11.2015 um 16:48 schrieb Johnny:
> >> Ich dachte immer, dass wir den tunnel nicht verschlüsseln, da nur eine
> >> end-to-end-verschlüsselung wirklich sinnvoll ist, und
> >> somit der anwender sich selbst um die verschlüsselung kümmern sollte,
> >> wenn er dies wünscht.
> >> Die CPU-Last ist aber sicherlich auch ein Argument was dagegen spricht.
> >>
> >> Gruss Johnny
> >>
> >>
> >> On 17.11.2015 14:02, Peter J. Philipp wrote:
> >>> Das weiss ich leider nicht.  Ich würde denken da muss irgendwas auf dem
> >>> Chip sein für AES oder TKIP?
> >>> Da das ja 150 Mbit router sind soweit ich weiss.  Treiber dafür haben
> >>> Freifunk warscheinlich nicht, sonnst würden wir es ja nutzen um zu
> >>> verschlüsseln.  Ich weiss noch vor ein paar jahren wurde mir gesagt wir
> >>> verschlüsseln nicht da die CPU zu lahm ist.  Aber als ich fastd
> >>> studierte wurde mir klar das wir eine kryptographische summe wenigstens
> >>> mit rein schreiben um MITM zu unterdrücken.
> >>>
> >>> Grüsse,
> >>>
> >>> -peter
> >>>
> >>> On 11/17/15 13:27, Emil Lefherz wrote:
> >>>> Ne Verschlüsselung gibt die Hardware nicht her, oder?
> >>>> Das wäre eine sinnvolle Idee. bei einem globalen Netzwerk wie dem
> >>>> Internet macht nationales Recht meines Erachtens nach eh wenig Sinn.
> >>>>
> >>>> lg emil
> >>>>
> >>>> On 11/17/2015 01:19 PM, Peter J. Philipp wrote:
> >>>>> Um den Leuten es klar zu machen... Na klar werden auch wir überwacht.
> >>>>> Das kann ich nicht beweisen aber es macht nur Sinn.  Wo würde ich uns
> >>>>> überwachen?  An den tunnel servern oder genauer gesagt vor den Tunnel
> >>>>> Servern.  So weit ich weiss wird der Tunnel nicht verschlüsselt und da
> >>>>> bemächtigen sich der BND und Verfassungsschutz.  Alles was die brauchen
> >>>>> ist ein schreiben an die provider der Tunnel Server zu machen und
> >>>>> können
> >>>>> dann heimlich in Freifunk internen sachen rumschnüffeln.  Wir sind auch
> >>>>> nicht besonderlich dagegen sonst hätten wir schon längst die Tunnel
> >>>>> verschlüsselt.
> >>>>>
> >>>>> Grüsse,
> >>>>>
> >>>>> -peter
> >>>>> _______________________________________________
> >>>>> franken mailing list
> >>>>> franken at freifunk.net
> >>>>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> >>>>>
> >>>> _______________________________________________
> >>>> franken mailing list
> >>>> franken at freifunk.net
> >>>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> >>> _______________________________________________
> >>> franken mailing list
> >>> franken at freifunk.net
> >>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> >> _______________________________________________
> >> franken mailing list
> >> franken at freifunk.net
> >> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> >
> 
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20151117/24f907f9/attachment.sig>