Opportunistic Encryption - Revision history

Henryk: /* Links */

2005-10-17T04:28:25Z

Links

← Older revision		Revision as of 04:28, 17 October 2005
Line 121:		Line 121:

	(Das gleiche Problem tritt zwar prinzipiell auch mit 'normalem' IPsec, etwa mit X.509-Zertifikaten auf, da es dort aber nur wenige Gegenstellen betrifft, und auch die nur ein einziges mal nach jedem Reboot, wiegt es dort weniger schwer.)		(Das gleiche Problem tritt zwar prinzipiell auch mit 'normalem' IPsec, etwa mit X.509-Zertifikaten auf, da es dort aber nur wenige Gegenstellen betrifft, und auch die nur ein einziges mal nach jedem Reboot, wiegt es dort weniger schwer.)

			=Links=
			[http://www.usenix.org/publications/login/1999-12/features/harmful.html IKE/ISAKMP considered harmful]

Henryk: /* DNS freigeben */

2005-09-13T01:13:10Z

DNS freigeben

← Older revision		Revision as of 01:13, 13 September 2005
Line 80:		Line 80:
	ein.		ein.

	Falls der DNS-Server lokal läuft sollte man Verschlüsselung auf dem lo-Device verbieten, ~~indem~~ ~~man~~ ~~dort~~		Falls der DNS-Server lokal läuft sollte man Verschlüsselung auf dem lo-Device verbieten. Der übliche Weg dazu wäre, in die <tt>/etc/ipsec.d/policies/clear</tt>
	127.0.0.0/8		127.0.0.0/8
			einzutragen. Das führt leider dazu, dass FreeS/WAN völlig abstruse Routen setzt. (Eine Kopie der Default-Route, aber für 127.0.0.0/8, also sowas wie <tt>127.0.0.0/8 via 10.0.23.1 dev eth0</tt>.)
⚫	~~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.

		⚫	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 <var>/usr/local/bin/dnsclear</var>) erzeugen mit folgendem Inhalt (<var>a.b.c.d</var> durch die eigene IP-Adresse ersetzen):		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 <var>/usr/local/bin/dnsclear</var>) erzeugen mit folgendem Inhalt (<var>a.b.c.d</var> durch die eigene IP-Adresse ersetzen):
Line 94:		Line 96:

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

			An dieser Stelle sollte man dann auch besser die Policy für das Loopbackdevice eintragen, indem man zu dem Skript noch
			spdadd 127.0.0.0/8 127.0.0.0/8 any -P in none;
			spdadd 127.0.0.0/8 127.0.0.0/8 any -P out none;
			hinzufügt (und dann die 127.0.0.0/8 <em>nicht</em> in <tt>/etc/ipsec.d/policies/clear</tt> einträgt).

	<!--		<!--

192.168.4.128: /* Keys erzeugen */

2005-09-12T10:20:31Z

Keys erzeugen

@@ Line 31: / Line 31: @@
 =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.
@@ Line 42: / Line 50: @@
  --DNS_RESOURCE_RECORDS--
 =DNS freigeben=

192.168.4.128 at 07:29, 12 September 2005

2005-09-12T07:29:15Z

← Older revision		Revision as of 07:29, 12 September 2005
Line 57:		Line 57:
	#!/usr/sbin/setkey -f		#!/usr/sbin/setkey -f

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

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

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

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

	=Probleme=		=Probleme=

Henryk: /* Probleme */

2005-09-10T21:45:32Z

Probleme

← Older revision		Revision as of 21:45, 10 September 2005
Line 66:		Line 66:

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

			=Probleme=
			Leider ist Opportunistic Encryption so quasi unbrauchbar, zumindest mit dem Kernel-IPsec. Wenn nämlich erstmals eine Verbindung zu einer Adresse aufgebaut werden soll, für die zur Zeit kein Policy-Eintrag existiert (also weder eine Security Association besteht, noch ein Vermerk dass der Empfänger kein IKE spricht und vorerst kein IPsec mit ihm versucht werden soll), dann erhält die auslösende Applikation für ihren <tt>connect()</tt>-Aufruf den Fehlercode <tt>EAGAIN (Resource temporarily unavailable)</tt>. Das 'temporarily' ist zwar durchaus ernst gemeint, denn wenige Sekunden später würde der Aufruf glatt durchgehen, dennoch brechen die meisten Programme an dieser Stelle mit einer Fehlermeldung ab:
			henryk@gleam ~ $ ping www.spiegel.de
			connect: Resource temporarily unavailable
			oder
			henryk@gleam ~ $ lynx http://www.hu-berlin.de/

			Suche nach www.hu-berlin.de
			HTTP-Verbindung zu www.hu-berlin.de wird aufgebaut.
			Obacht: Verbindung zum remote Host konnte nicht hergestellt werden.

			lynx: Unzugängliche Startdatei http://www.hu-berlin.de/
			etc. pp.

			(Das gleiche Problem tritt zwar prinzipiell auch mit 'normalem' IPsec, etwa mit X.509-Zertifikaten auf, da es dort aber nur wenige Gegenstellen betrifft, und auch die nur ein einziges mal nach jedem Reboot, wiegt es dort weniger schwer.)

Henryk: /* Software */

2005-09-10T20:53:59Z

Software

← Older revision		Revision as of 20:53, 10 September 2005
Line 4:		Line 4:
	=Software=		=Software=

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

	Wir haben für unsere Installation Debian Sarge verwendet mit Kernel 2.6.		Wir haben für unsere Installation Debian Sarge verwendet mit Kernel 2.6.
Line 14:		Line 14:
	</pre>		</pre>

	Das eigentlich aktuellere ~~OpenSwan~~ in derzeit für OE leider nicht geeignet.		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:		Zumindest bei kernel-2.6.8 besteht das Problem, dass die folgende Fehlermeldung kommt:

Line 23:		Line 23:
	Im Verzeichnis openswan-*/doc/2.6.known-issues steht das zumindest unter CURRENT ISSUES.		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 <tt>/etc/init.d/ipsec</tt> 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 <tt>/var/log/auth.log</tt>, wo man sie intuitiv eher nicht vermuten würde. Fehlersuche gestaltet sich aber leicher, wenn man die Logs hat ;-).

	=Keys erzeugen=		=Keys erzeugen=

Henryk: /* DNS freigeben */ Fipptehler

2005-09-10T20:22:52Z

DNS freigeben: Fipptehler

← Older revision		Revision as of 20:22, 10 September 2005
Line 52:		Line 52:
	#!/usr/sbin/setkey -f		#!/usr/sbin/setkey -f

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

Henryk: /* DNS freigeben */

2005-09-10T17:39:35Z

DNS freigeben

@@ Line 28: / Line 28: @@
 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.
 In der Datei befindet sich dann der DNS-Record:
 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

192.168.4.128 at 13:14, 9 September 2005

2005-09-09T13:14:44Z

← Older revision		Revision as of 13:14, 9 September 2005
Line 1:		Line 1:
	==Hardware==		=Hardware=
	Beliebige Rechner, auf denen Linux mit Kernel 2.4 oder 2.6 drauf läuft.		Beliebige Rechner, auf denen Linux mit Kernel 2.4 oder 2.6 drauf läuft.

	==Software==		=Software=

	FreeSwan auf mindestens zwei verschiedenen Rechnern und einen DNS-Server.		FreeSwan auf mindestens zwei verschiedenen Rechnern und einen DNS-Server.

192.168.4.128 at 13:13, 9 September 2005

2005-09-09T13:13:04Z

← Older revision		Revision as of 13:13, 9 September 2005
Line 15:		Line 15:

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

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

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


	=Keys erzeugen=		=Keys erzeugen=
Line 50:		Line 58:

	Falls der DNS-Server lokal läuft sollte man Verschlüsselung auf dem lo-Deviceverbieten, indem man folgendes in die /etc/ipsec.conf einträgt.		Falls der DNS-Server lokal läuft sollte man Verschlüsselung auf dem lo-Deviceverbieten, indem man folgendes in die /etc/ipsec.conf einträgt.
			(Steht auch im doc/* drin.)

	<pre>		<pre>