[solved] Buster, OpenVPN: CA erneuern, läuft bald ab

[ingo2]

Seit Jahren läuft mein OpenVPN-Server brav auf meinem Serverlein. Nutze den praktisch nur vom Laptop aus, wenn ich mit dem von außerhalb ins Internet gehe.

Für die OpenVPN-Zertifikate habe ich damals TinyCA2 benutzt, die dafür erstellte CA hat aber nur eine Gültigkeit von 10 Jahren und die läuft demnächst ab. Mir bleibt also nichts anderes übrig als die ganze Prozedur: neue CA, neue client- und server-keys, signing-requests, neue DH-Parameter, ... nochmals zu machen.

Jetzt habe ich auf den Projektseiten gelesen, daß die graphischen Tools wie TinyCA und gnoMint nicht mehr gepflegt werden (z.B. nur sha1 als Hash-Algorithmus) und suche eine Alternative. Da scheint wohl easy-rsa recht praktisch zu sein, da finden sich mehrere gute HowTo's zu, z.B. https://wiki.archlinux.org/index.php/OpenVPN und https://wiki.debian.org/OpenVPN. Nachdem inzwischen alle Systeme bei mir OpenVPN v2.4 und easy-rsa v3.0 nutzen, sollte es möglich sein, mit "elliptischen Kurven" zu arbeiten https://forums.openvpn.net/viewtopic.php?t=23227. Damit soll dann auch der "Diffie-Hellmann-Parameter" überflüssig sein (s. https://serverfault.com/questions/10076 ... ptic-curve und https://forums.openvpn.net/viewtopic.php?t=23227). Hört sich gut an - hat das schon Jemand erfolgreich probiert?
Gibt es dabei etwas besonderes zu beachten?
Kann der NetworkManager (auf dem Client) damit umgehen?

Es gäbe aber eine weitere recht einfache Lösung, s. https://openvpn.net/community-resources ... ini-howto/ mit statischem Key und würde für meinen Bedarf (derzeit nur 1 Client) auch ausreichen. Die Keys kann ich ja problemlos per SSH verteilen.
Gibt es da Sicherheitsbedenken?

Oder welches Tool ist sonst empfehlenswert - es gibt ja auch noch "/usr/lib/ssl/misc/CA.pl"?

Oder lohnt es sich, auf Bullseye zu setzen und gleich Wireguard verwenden?

Grüße, Ingo

[TomL]

Jetzt habe ich auf den Projektseiten gelesen, daß die graphischen Tools wie TinyCA und gnoMint nicht mehr gepflegt werden (z.B. nur sha1 als Hash-Algorithmus) und suche eine Alternative. Da scheint wohl easy-rsa recht praktisch zu sein

Nein, SHA1 ist seit Jahren schon keine Alternative mehr. Und Ja, easyrsa ist sogar eine sehr gute Alternative. Ganz nebenbei bemerkt, ich nutze OpenVPN seit mehr als 10 Jahren, aber ich wäre nie auf die Idee gekommen, irgendein suspektes Fremdtool zur Erzeugung einer PKI zu nutzen. easyrsa ist hingegen nur ein Script, was man auch 'lesen' kann, und es verwendet direkt openssl.

Nachdem inzwischen alle Systeme bei mir OpenVPN v2.4 und easy-rsa v3.0 nutzen, sollte es möglich sein, mit "elliptischen Kurven" zu arbeiten. Damit soll dann auch der "Diffie-Hellmann-Parameter" überflüssig sein

Ja, stimmt, ist möglich. Nein, sind sie nicht. Wenn Du keine eigenen DH-Parameter erzeugst, werden Hardcoded-Parameter verwendet. Das ist ein Unsicherheitsfaktor... wie relevant das ist, hängt von der Anwendung und dem Level des angestrebten Schutzes ab.

... - hat das schon Jemand erfolgreich probiert? Gibt es dabei etwas besonderes zu beachten?

Ja, ich. Ja muss man... man muss das bei der Zertifikat-Erstellung explizit vorsehen.

Kann der NetworkManager (auf dem Client) damit umgehen?

Keine Ahnung, ich halte den eh für Bloatware und verwende den nicht. Aber meiner Meinung nach hat der NWM da eh nix mit zu tun. Ob EC oder RSA ist eh eine Sache auf OpenVPN-Prokokoll-Ebene.... da wird der NWM vermutlich gar nichts von mitbekommen.

Es gäbe aber eine weitere recht einfache Lösung, mit statischem Key und würde für meinen Bedarf (derzeit nur 1 Client) auch ausreichen. Die Keys kann ich ja problemlos per SSH verteilen. Gibt es da Sicherheitsbedenken?

Sicherheitsbedenken wogegen? Gegen SSH oder gegen den Static-Key. Fakt ist, ein Static-Key hat nichts mit der Anzahl von Clients zu tun. Die Relevanz liegt an anderer Stelle. Ein Static-Key macht eine statische Verschlüsselung... also ganz egal, was Du wann und über welchen Zeitraum tust, mit einem gehackten Static-Key sind rückwirkend sämtliche mitgeschnittene Sitzungen aus der Vergangenheit ganz einfach zu entschlüsseln. Ob das wieder relevant ist...?.... hängt vom Level des angestrebten Schutzes ab. Die sichere Alternative ist "Perfect Forward Secrecy", bei der nur ephemere Schlüssel (Einmalschlüssel) verwendet werden.

Oder welches Tool ist sonst empfehlenswert

äh... easyrsa...!

Oder lohnt es sich, auf Bullseye zu setzen und gleich Wireguard verwenden?

Bullseye oder Buster hat nichts mit der Frage OpenVPN oder Wireguard zu tun. WG ist bei nur einem Client sicher eine Alternative... die Antwort auf diese Frage kannst nur Du selber herausfinden.

[ingo2]

Dank @TomL,

ist wirklich sehr informativ - damit werde ich easy-rsa verwenden.
Das mit WireGuard fällt noch aus einem anderen Grunde weg - das kann ausschließlich über UDP tunneln. Wenn ich dann dadurch SIP-Telefonie machen will (mit Linphone) - das nutzt auch UDP, kann es sein, daß die Angelegenheit wackelig wird.

Noch eine zusätzliche Frage:
wenn sich schon Diffie-Hellmann auf jeden Fall lohnt, macht es dann noch Sinn, "elliptic curves" zu nutzen (Serverlast ist hier uninteressant), oder bleibe ich besser bei lang erprobten RSA-Schlüsseln?

Gruß, Ingo

[TomL]

wenn sich schon Diffie-Hellmann auf jeden Fall lohnt, macht es dann noch Sinn, "elliptic curves" zu nutzen (Serverlast ist hier uninteressant), oder bleibe ich besser bei lang erprobten RSA-Schlüsseln?

Dabei gehts jetzt nicht um lohnend oder nicht, sondern um zu verhindern, hardcoded Parameter zu verwenden. Und ob EC oder RSA verwendet wird, ist für die spätere Sitzung, in der ein Einmalschlüssel als statischer Schlüssel verwendet wird, irreleveant. EC oder RSA ist nur am Anfang der Sitzung für die Schlüsselverhandlung wichtig, beides hat für die anschließende Sitzung keine weitere Bedeutung. Im übertragenen Sinne bedeutet das, die Initiierung der Sitzung basiert auf einer asymmetrischen Verschlüsselung, die eigentliche Sitzung danach auf symmetrischer Verschlüsselung.

RSA3072 oder RSA4096 ist nach heutigen Wissen nicht zu knacken, EC selbstverständlich auch nicht. Aber die Betonung liegt auf "heutiges Wissen" bzw. Stand der Hardwaretechnik. Aber bei dem Aspekt ist allerdings deutlich relevanter, dass, selbst wenn RSA gehackt wurde, vergangene Sitzungsschlüssel nicht reproduziert werden können.... weils eben ephemere Schlüssel sind. Und wenn RSA, damits mal nicht eben zwischendurch gehackt werden kann, dann RSA3072. Das reicht nach heutigem Wissen.

[ingo2]

Also, mache ich's genauso wie bisher, nur mit einer neuen CA und easy-rsa. D.h. 4096-bit RSA-Schlüssel und Diffie-Hellmann-Parametern.

Jetzt habe ich gesehen, daß die Installation von easy-rsa auch opensc als recommends vorschlägt.
Wäre großartig, wenn ich dann meinen bereits vorhandenen 4096-bit GPG/SSH-Auth-Key von einem Yubikey für den Client nutzen könnte.
Sollte doch eigentlich gehen, von der CA wird ja nur der public-key signiert und dann als *.pem oder *.pkcs12 exportiert? Dazu findet man aber keinerlei Doku.

Gruß,
Ingo

[TomL]

Jetzt habe ich gesehen, daß die Installation von easy-rsa auch opensc als recommends vorschlägt. Wäre großartig, wenn ich dann meinen bereits vorhandenen 4096-bit GPG/SSH-Auth-Key von einem Yubikey für den Client nutzen könnte.

Da weiß ich jetzt nicht, ob ich Dich richtig verstehe. Aber einer SSH-Verbindung sollte es eigentlich völlig egal sein, ob irgendwo auf der Netzwerkstrecke vom Client zum Server ein Teilstück durch einen Tunnel führt.... soll heißen, SSH wird das nicht mal bemerken, dass da ein Tunnel ist. Die einzige Besonderheit ist, Du verschlüsselst mit SSH zusätzlich -also ein zweites Mal- durch einen bereits sicher verschlüsselten Tunnel.

[ingo2]

Da weiß ich jetzt nicht, ob ich Dich richtig verstehe.

Das habe ich anders gemeint:

Ich habe einen starken GPG-Key mit 3 Sub-Keys (sign, decrypt und authentication) und die liegen auf auf einem Yubikey. Auf dem Rechner, an dem ich den Yubikey benutze sind dann nur noch die Stubs, welche auf den Yubikey verweisen. Dort läuft dann auch der gpg-agent mit der Option "enable-ssh-support" in der "gpg-agent.conf". Damit kann ich außer für GPG (decrypt, sign) selbst den Yubikey auch zum SSH-Login (auth) benutzen.

Meine Idee war jetzt, wie bei SSH auch den Yubiky für "auth" mit OpenVPN anstelle des Client-Keys zu nutzen.
Das wäre eine sehr sichere und komfortable Lösung.
Also nur eine Stelle (auf dem Yubikey) wo der private-key liegt und ein Passwort (das vom Yubikey) zur Nutzung für 3 verschiedenen Anwendungen: GPG, SSH, VPN.

Also echte 2-Faktor Authentifizierung: Den Yubiky besitzen (und sein Passwort kennen) und den Rechner mit den passenden Stubs (und dem passenden ta.key) haben.

Ingo

[ingo2]

So habe mir easy-rsa jetzt mal genauer angesehen - mit der aktuellen Version 3.x unter Buster wird das Erstellen der Zertifikate damit ein Kinderspiel im Gegensatz zu vor 10 Jahren unter Wheezy.
Damit verwerfe ich das mit dem Yubikey (wäre halt sehr komfortabel und sicher gewesen).

Thread gelöst,
Danke an @TomL