Linux-VPN WireGuard will nun doch auf Kernel-Krypto-API umsteigen
Im Konflikt mit den Kernel-Entwicklern über Krypto-Funktionen zeichnet sich ein Kompromiss ab.
(Bild: WireGuard / pixabay (Collage))
Das relativ neue VPN-Protokoll WireGuard wird von vielen Linux-Nutzern als Alternative zu OpenVPN und IPSec gehandelt. Die Entwickler des Open-Source-Projektes haben es sich nach eigenen Angaben zum Ziel gesetzt, ein einfach zu benutzendes und dennoch maximal sicheres VPN-Werkzeug zu bauen. Ihnen ist dabei besonders wichtig, die Code-Basis des Projekts möglichst schmal zu halten, um Security-Audits durch unabhängige Sicherheitsforscher so einfach wie möglich zu machen.
Dieses Ziel läuft aber bisher ihren Plänen zuwider, WireGuard in den Hauptentwicklungszweig des Linux-Kernels zu bekommen. Trotz Unterstützung durch Linux-Chef Linus Torvalds verhinderten diverse Kontroversen dies bisher. Jetzt könnte Bewegung in die Sache kommen.
Torvalds adelt den WireGuard-Code
Torvalds selbst hatte WireGuard im vergangenen Jahr gelobt, als er den Quellcode der Software im Vergleich "zum Horror" bei OpenVPN und IPSec als "Kunstwerk" bezeichnet hatte. Der Linux-Chefentwickler hatte dabei auch die Hoffnung geäußert, dass WireGuard schnell in der Mainline landet, dem Hauptentwicklungszweig des Linux-Kernels. Das ist bisher nicht passiert, da WireGuard für seine Verschlüsselungs-Operationen ein eigenes Krypto-API namens Zinc mitbringt, das ebenfalls in den Kernel integriert werden müsste. Nun hat der Kernel aber schon ein eigenes API für diese Zwecke und die Kernel-Entwickler beharrten bisher auf dem Standpunkt, dass die WireGuard-Leute doch bitte die vorhandene Technik benutzen sollten.
Bisher hatte WireGuard-Chefentwickler Jason Donenfeld immer darauf bestanden, dass sein Ziel einer maximal kleinen – und damit maximal sicheren – Code-Basis mit der vorhandenen Kernel-API nicht zu machen sei. Die Kernel-API sei zwar gut geschrieben, aber eben auch viel zu umfangreich, schwer zu benutzen und "ein Cipher-Museum" – sie enthalte seiner Meinung nach zu viele veraltete und unsichere Krypto-Algorithmen. Seine Hauptkritik zielt darauf, dass niemand wisse, welche Algorithmen vertrauenswürdig sind. Er bevorzuge Krypto, die von externen Quellen mittels nachvollziehbarer Audits dokumentiert sei, sagte Donenfeld im vergangenen Jahr gegenüber dem Branchenmagazin LWN.
Kompromissbereitschaft
Nachdem die WireGuard-Entwickler mehr als ein Jahr mit Auseinandersetzungen über Zinc verbracht haben, die auch ihre VPN-Software an einer Aufnahme in die Kernel-Mainline hinderten, zeigen sie sich nun kompromissbereit. Sie denken nun offenbar darüber nach, beide Software-Komponenten zu entkoppeln und getrennt voneinander in den Hauptentwicklungszweig des Kernels einfließen lassen. Dazu muss WireGuard zuerst auf das vorhandene Krypto-API portiert werden. Dann dürfte dem Segen der Linux-Entwickler nichts mehr im Wege stehen. Erst danach wolle man sich dann wieder Zinc zuwenden und versuchen, dieses Projekt ebenfalls in die Mainline zu bekommen.
Der neue Plan soll bewirken, dass WireGuard nun schnell Teil des Kernels wird und dass Donenfeld mit etwas Glück am Ende doch noch seinen Willen bekommt und das Team die VPN-Software dann später auf Zinc zurückportieren kann. Noch scheinen sich die beteiligten Entwickler allerdings nicht ganz einig zu sein, ob dies das beste Vorgehen ist.
Aufnahme in die Mainline birgt viele Vorteile
Aber warum ist es für die Entwickler überhaupt so wichtig, in den Hauptentwicklungszweig des Kernels aufgenommen zu werden? Der Hauptvorteil liegt sicherlich darin, dass ihr VPN-Protokoll dann jedem zur Verfügung steht, ohne auf spezielle Kernel-Patches seiner Distribution angewiesen zu sein. Das erhöht die Verfügbarkeit der Technik in der Regel drastisch und macht reine Userland-Umsetzungen der Technik unnötig.
Außerdem vereinfacht eine Aufnahme in die Mainline den Upstream-Entwicklungsprozess für die WireGuard-Entwickler und stärkt die Zusammenarbeit mit den Kernel-Entwicklern. Als Nebeneffekt wird es für andere Projekte einfacher, den WireGuard- und Zinc-Code in ihrer eigenen Software zu nutzen.
(ovw)
