[Berlin-wireless] freifunk PKI

[Sven-Ola Tuecke]

Hallo Daniel,

was man in jedem Fall machen koennte: die Gateway-Betreiber weisen sich aus, 
z.B. mit einem CA-CERT. Und bieten damit einen verschluesselten Datenpfad 
bis zum Gateway/Tunnelendpunkt. Dann kann man sich immerhin sicher sein, 
dass nur der Gateway-Betreiber schnueffeln kann.

// Sven-Ola

"Daniel Golle" <daniel.golle at gmail.com> schrieb im Newsbeitrag 
news:mailman.2393.1272889286.10856.berlin at berlin.freifunk.net...

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

> Daniel Golle schrieb:
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?)