Opportunistic Encryption

Hardware

Beliebige Rechner, auf denen Linux mit Kernel 2.4 oder 2.6 drauf läuft.

Software

FreeS/WAN auf mindestens zwei verschiedenen Rechnern und einen DNS-Server.

Wir haben für unsere Installation Debian Sarge verwendet mit Kernel 2.6.

Mit Debian reicht ein

apt-get install freeswan

Das eigentlich aktuellere OpenS/WAN in derzeit für OE leider nicht geeignet. Zumindest bei kernel-2.6.8 besteht das Problem, dass die folgende Fehlermeldung kommt:

Sep  9 09:17:45 localhost pluto[13449]: %hold otherwise handled during DNS lookup for Opportunistic Initiation for 10.0.42.2 to 10.0.23.2

Im Verzeichnis openswan-*/doc/2.6.known-issues steht das zumindest unter CURRENT ISSUES.

Achtung: Das Initskript hat unter Debian Probleme damit, den pluto-daemon ordnungsgemäß zu beenden. Am einfachsten fügt man daher in /etc/init.d/ipsec an passender Stelle (FIXME) die Zeile

killall _plutorun pluto _plutoload _pluto_adns

ein.

Debugging-Hinweis: Bei Debian landen die Logs von pluto in der Datei /var/log/auth.log, wo man sie intuitiv eher nicht vermuten würde. Fehlersuche gestaltet sich aber leicher, wenn man die Logs hat ;-).

Keys erzeugen

Um DNS-Einträge mit Schlüsseln zu erzeugen nimmt man ipsec mailkey. Dieses Tool generiert eine ausführbare Datei in der die TXT Records stehen, die man in das Reverse-DNS eintragen muss.

ipsec mailkey --me test@localhost --reverse 10.0.23.2

In der Datei befindet sich dann der DNS-Record:

--DNS_RESOURCE_RECORDS--

2.23.0.10.in-addr.arpa. IN      TXT     "X-IPsec-Server(10)=10.0.23.2" "lakdfklajsdfoiweruo82347.... "

--DNS_RESOURCE_RECORDS--

DNS freigeben

Wenn man nun die Rechner die Records eingetragen hat, muss man noch dafür sorgen, dass DNS-Anfragen beim Aushandeln der Schlüssel nicht der OE zum Opfer fällt. Dazu trägt man am besten den DNS-Server in die Datei /etc/ipsec.d/policies/clear in Form von

a.b.c.d/32

ein.

Falls der DNS-Server lokal läuft sollte man Verschlüsselung auf dem lo-Device verbieten, indem man dort

127.0.0.0/8

einträgt. Ausserdem wird der lokale DNS-Server selbst DNS-Anfragen absetzen wollen (zum Beispiel, wenn FreeS/WAN versucht, herauszufinden ob für die eigene IP wirklich ein korrekter TXT-RR existiert) was zu einer Henne-und-Ei-Situation führt: Zum Nachschlagen der Schlüssel ist DNS erforderlich, für jedweden Netzwerkverkehr müssen aber Schlüssel nachgeschlagen werden.

Die Policy-Groups von FreeS/WAN können Verkehr leider nur nach IP-Adressen einordnen und unterstützen keine weiteren Kriterien wie etwa Portnummern oder gar Paketfilter-Tags, obwohl das darunterliegende Kernel-IPsec das durchaus kann. Workaround: Man setzt die passenden Policyregeln manuell mit setkey. Dazu muss man ein setkey-Skript (zum Beispiel /usr/local/bin/dnsclear) erzeugen mit folgendem Inhalt (a.b.c.d durch die eigene IP-Adresse ersetzen):

#!/usr/sbin/setkey -f

spdadd a.b.c.d/32 0.0.0.0/0[53] udp -P out prio high + 1073739721 none;
spdadd a.b.c.d/32 0.0.0.0/0[53] tcp -P out prio high + 1073739721 none;

spdadd 0.0.0.0/0[53] a.b.c.d/32 udp -P in prio high + 1073739721 none;
spdadd 0.0.0.0/0[53] a.b.c.d/32 tcp -P in prio high + 1073739721 none;

Dieses Skript trägt man dann in /etc/ipsec.conf im Abschnitt config setup als prepluto="/usr/local/bin/dnsclear" ein. Das Skript sollte natürlich ausführbar sein (chmod a+x /usr/local/bin/dnsclear).

Die Angabe der Priorität ist notwendig damit die neuen Regeln die von Pluto (mit einer irrwitzig hohen Priorität) erstellten Regeln überdecken, funktioniert jedoch laut manpage von setkey nur mit Kerneln ab 2.6.6.