Staan de andere vpn-oplossingen ook in de kernel? Waarom wel/niet?

Lees maar na op https://www.wireguard.com/

Een kwestie van snelheid, door het in de kernel te zetten sla je één stap over.

Als je bij "VPN-oplossingen" denkt aan de diverse VPN-providers dan moet je beseffen dat Wireguard is niet een provider is die wordt voorgetrokken maar een protocol met een open source-implementatie. De Engelstalige Wikipedia noemt twee providers die het ondersteunen, en er is geen enkele reden waarom anderen het niet zouden kunnen gaan ondersteunen.
En afgaande op wat Torvalds in de in het artikel gelinkte LKML-post schrijft is de code van aanzienlijk betere kwaliteit dan die van OpenVPN en IPSec. Goed opgezette, elegante programmacode is een belangrijke factor voor een goede onderhoudbaarheid en lager bug-gevoeligheid, en daar maakt Torvalds volkomen terecht een belangrijk punt van.

Poorten communicatie naar buiten zou je niet onder root moeten willen draaien.
W3c heeft echt bepaald dat poorten onder de 1024 onder root moeten. Je zou die onderlaag moeten herontwerpen met een gescheiden geïsoleerde security.https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html.
Ja selinux (source van NSA) helpt wat maar is geen herontwerp in benodigde security lagen.


De status van wireguard is wat anders. Kijk op de genoemde link, dan staat er: https://www.wireguard.com/#work-in-progress
"WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come."

Maak je geen zorgen karma4, de experts zijn aan het werk hiermee. Het komt goed! Meer dan goed zelfs! Geloof me.

kant, wal en karma4 .
Bingo, we hebben weer een voorbeeld.

karma4 snapt het verschil niet tussen een userland daemon die al dan niet met root privileges draait, en kernelspace code.
root privilege is niet hetzelfde als 'kernelspace' . Een een daemon op een bepaalde poort is geen protocol driver.

de wireguard module kun je conceptueel vergelijken met bv de IPv6 module, of de GRE module, of de IPX module .
Ook (old skool) ppp is een voorbeeld - een kernel module voor de packet handling, en userland daemon die de handshake en negotiation doet.
Dat zijn betere voorbeelden dan apache of ssh voor de rol van het kernel deel van wireguard.

Nou, volg ik het een beetje, dus wist ik al wel dat er enhousiasme is hiervoor.

Maar 'Geloof me' is niet een heel goed argument om beveiligssoftware aan te prijzen. :-)

Tevens Linus Torvalds is goed in het beoordelen van code, dus de code kwaliteit zal wel goed zijn, maar hij is geen crypto expert, dus het protocol kan hij niet beoordelen.

De onderlaag hoeft niet herontworpen te worden, de gescheiden geïsoleerde security wordt ook zonder SELinux prima ondersteund. Grappig genoeg staat op de pagina waarvan je de URL hebt geplakt (zonder er even url-tags omheen te zetten) al iets daarover vermeld:
Versie 2.14 van httpd is van 1993, dit was 25 jaar geleden al een opgelost probleem. Je moet je kennis eens bijspijkeren.

Sterker nog, het is perfect mogelijk, en dat wordt ook toegepast, om alleen een simpel programma'tje als root te laten draaien, dat niets anders doet dan de privileged poort openen, zijn rechten naar een non-privileged user degraderen, en zichzelf vervolgens door een andere executable te vervangen die de open poort erft en requests afhandelt. De code die als root draait is zo overzichtelijk en simpel dat hij erg goed veilig te maken is, hij opent wel de poort maar handelt geen requests af; de code die dat wel doet, complexer en foutgevoeliger is, wordt dan niet eens in het procesgeheugen geladen tot nadat de root-rechten zijn vervallen.

Gelukkig werken er mensen aan de kernel mee die dat wel kunnen beoordelen, en draagt een goede kwaliteit van de code in hoge mate bij tot het kunnen beoordelen daarvan.

Dat is gaaf - temeer W3C zich helemaal niet bezighoudt met poortnummers, laat staan Linux-kernelontwikkeling :D
De mate waarin er privileges binnen een besturingssysteem vereist zijn om een service al dan niet op een zeker poortnummer onder de 1024 toe te laten, is toch echt de keuze van een besturingssysteem c.q. netwerkstack.

De Internet Assigned Numbers Authority (IANA) bestiert zich daar sinds zo'n jaar of dertig mee. Zoals ze het zelf zo mooi zeggen:

Het actuele overzicht van gereserveerde en toegewezen poortnummers treft men aan op diens website:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

Met poortnummers geldt hetzelfde als met zoveel dingen op internet: 't zijn conventies, afspraken; geen vereisten.

@karma4: Verlang jij terug naar de tijd van X.25? Ik niet :-)

"WireGuard VPN review: A new type of VPN offers serious advantages" by Jim Salter in Ars Technica, Aug 26, 2018
https://arstechnica.com/gadgets/2018/08/wireguard-vpn-review-fast-connections-amaze-but-windows-support-needs-to-happen/

Vers van de pers.

Het artikel geeft voorbeelden van de toepassing van WireGuard onder Ubuntu. Blijkbaar kan het dus wel, een compacte code base er op nahouden. Illustratief is het verschil in grootte tussen een WireGuard vs. een OpenVPN key.