[Berlin-wireless] freifunk PKI

Daniel Golle daniel.golle
Mo Mai 3 14:20:50 CEST 2010


On May 3, 2010, at 1:39 PM, Daniel Nitzpon wrote:

> Daniel Golle schrieb:
>>> Sven-Ola Tuecke schrieb:
>>>> - Ein Freifunk_Tribunal trifft sich jeden Montag - Aspiranten
>>>> muessen eine Initiationspruefung ablegen
> 
>> Fakt ist am status-quo freifunk einfach nun mal folgendes: neben
>> T-Com, BND und BKA kann bei Verwendung unsicherer Services (z.B.
>> HTTP, SIP, POP3, IMAP, SMTP, ...) jetzt zuaetzlich auch noch jeder
>> Passant an der Strassenecke mithoeren.
> 
> mir erschließt sich der vorteil/unterschied nicht wirklich. solange es um ein offenes netz geht, muss es für jeden relativ einfach möglich sein, neu einzusteigen. nach dem einstieg ist mithören dann sowieso möglich.
> klar ist irgendeine form von registrierung eine etwas größere hürde als ein einfaches apt-get install wireshark, aber so viel größer kommt sie mir für jemanden, der erstmal überhaupt die motivation zum mithören hat auch nicht vor.
> wo liegt also der unterschied/gewinn?
Es geht mir nicht um den Austausch eines Pre-Shared-Keys und auf keinen Fall um die Errichtung irgendwelcher Hürden. Jeder der unverschlüsselt kommunizieren will, kann/soll das gerne tun.
apt-get install wireshark hilft dem potentiellem Lauscher eben nur dann, wenn er in irgendeiner Form Zugang zur Klar-Text-Kommunikation hat. Wenn er nicht gerade T-Com oder Alice heisst oder einen grossen IP-Backbone betreibt, hat Otto-Normal-Mithörer da normalerweise erst mal Pech gehabt -- solange ich nicht gerade Klar-Text über ein offenes Funk-Netz kommuniziere. Eben das ist bei freifunk der Fall.
Ich persönlich fände, es wäre doch schön, wenn zumindest die optionale Möglichkeit zur Authentifikation und Verschlüsselung des IP-Verkehrs *innerhalb* des freifunk Netzes bestehen würde. Dann könnte ich mit meinem freifunk Nachbarn z.B. SIP Telefonieren, ohne das irgendjemand mithören kann. Klar, das geht jetzt schon, in dem wir uns bei CAcert X.509 Zertifikate ausstellen lassen und die dann für IPSec oder TLS-Anwendungen verwenden.
Wenn wir einen Weg zum Public-Key-Austausch in die IP-Vergabe Datenbank einbauen, wäre auf einem relativ leichtem Weg Platz für viele neue Möglichkeiten geschaffen und mehr Menschen wären Inspiriert, mit Verschlüsselungstechnik zu spielen. Gerne können da einfach mehrere optionale Felder für X.509 Zertifikat, PGP-Fingerprint und/oder Public-Key, etc. sein.
 
btw: X.509 Zertifikate müssen nicht nur vom Aussteller signiert sein, sondern können zudem auch von anderen Co-Signiert werden. Auch auf diese Art lässt sich ein Web-of-Trust organisatorisch Nachempfinden -- mit dem Vorteil, das sich X.509 in TLS/SSL, IPSec, etc. integrieren lässt. Um beim Verbindungsaufbau z.B. einer TLS-Anwendung dann eben auch einen Verifizierungspfad über die Co-Signer statt nur die CA zu respektieren, kann OpenSSL an der dafür vorgesehenen Stelle (verfify_callback) erweitert werden. Aber das ist noch Theorie.
Ebenso theoretisch fände ich es natürlich auch schöner, wenn racoon2 oder dergleichen beim Erstkontakt mit einem beliebigem Host einfach mal opportunistisch Zertifikate austaeuschen könnte. Leider ist der Certificate-Payload Typ von IKEv2 noch nirgendwo umgesetzt worden... (oder?)






Mehr Informationen über die Mailingliste Berlin