[wiregate] Neue OpenVPN CA und Server Zertifikat + Keys erstellen

[Shoko]

Hallo,

ich habe seit ein paar Jahren das Wiregate inklusive OpenVPN am Laufen, bisher ohne Probleme.
Letzte Woche habe ich mir auf meinem Laptop auf dem Arch Linux läuft Updates installiert, darunter war auch OpenSSL 1.1 was mir den VPN Zugang zum Wiregate "zerschoss".
Ab OpenSSL 1.1 sind Zertifikate die md5 oder sha1 als md Algorithmus verwenden deprecated, da die Algorithmen als gebrochen gelten, und es wird die Verbindung verweigert. Leider benutzt mein Wiregate OpenVPN Server noch so ein Zertifikat.

Das möchte ich ändern. Grundsätzlich wäre es kein Problem einfach CA, Key und Zertifikat neu zu erstellen, allerdings möchte ich das Ganze so machen, dass ich weiterhin über die Weboberfläche VPN Clients anlegen kann und die Konfiguration herunterladen. Was gibt's diesbezüglich zu beachten, muss ich bei der Erstellung der CA und Keys ein bestimmtes Passwort verwenden, bzw. wo wird das Passwort hinterlegt?

Und wie siehts mit dem TA.key aus? Muss der auch neu erstellt werden?

Danke und viele Grüße
Michael

[StefanW]

Hallo Michael,

das ist ein interessanter Punkt. Ich kann das nicht aus der holen Hand beantworten und bespreche das mit den Spezialisten intern.

lg

Stefan

[makki]

In der Tat eine interessante Frage..

Sollte im Prinzip easy sein, ganz grob (bitte nicht als Anfänger ausprobieren!):

0.)
/etc/openvpn/keys/this-server-ca/* sichern

1.)
in /etc/openvpn/openvpn-ssl.cnf

...
default_md    = sha256
...

Dann schauen wir uns in
/etc/init.d/reset-fallback.sh
an, wie ca.crt und server.crt erstellt werden

2.) erstellen /etc/openvpn/keys/this-server-ca/ca.* und /etc/openvpn/keys/this-server-ca/server.*
neu
(je nachdem: .key behalten!! dann gehen evtl. "alte Clients ohne anfassen weiterhin)

- restart openvpn
- verteilen des neuen ca.crt/ca.pem auf die clients
et voila..

So oder so ähnlich, nochmal: das ist keine Anleitung sondern nur der Hinweis, wo man hinlangen müsste. Bitte nicht als Anfänger ausprobieren!

-> eleganter wäre natürlich ein offizielles Update , was aber wie immer anstregend ist, tagelanges testen, etc.pp...
P.S.: auf meinem einzigen Testsystem Stand 1.4.0 ist aus unerfindlichen Gründen sogar md5 drin , wie das dahin kam=?? -> Das geht natürlich garnicht! (Default war in der Tat SHA1)

Final: einfacher ist sicherlich, dem allzu-progressiven Client beizubringen das SHA1-Cert halt zu schlucken - ja es ist gebrochen (SHAttered) aber m.E. sollte man das jetzt im nicht-VS-Umfeld mal nicht überbewerten, das mit enormer Rechenleistung theoretisch eine Kollision möglich ist.

-> Wenn mir mal fad ist, spiele ich es durch, ich brauch das VPN aber grade und hab keine Zeit ein dutzend Clients zu testen.. Also so in 2-20J

P.P.S.: warum hat man (ich) anno 2008 noch SHA-1 verwendet, obwohl schon seit 2005 bekannt war, das es gebrochen *werden könnte* ?
Ganz einfach: SHA256+ oder RMD160 ging damals bei vielen Clients default-mässig schlicht nicht, also Vorsicht bei alten OpenVPN/openssl-Versionen am Client..
Daher dürfte auch ein "Pauschal-Update" eine eher schlechte Idee sein. Bei neuen sollte es jedoch SHA256+ Usus sein.

Das WireGate jedenfalls kann es seit jeher.


Grüsse Makki

Edit: ta.key und dh1024.pem kann man behalten, die haben damit nicht zu tun. Dem Webinterface ist das egal, das erstellt Clients mit was auch immer (validem) in der openvpn-ssl.cnf steht..

[Shoko]

Danke schön, dann werd ich mal sehen ob ich's so wieder ans laufen bekomme.

[makki]

Ich hoffe die entscheidenden Hinweise gegeben zu haben; Feedback ob und wie genau es geht, ist aber sicherlich hilfreich.
Zwischen "ich weiss wies geht" (habe das bei mir natürlich schon vor Jahren geändert) und einem getesteten, für den Massenrollout tauglichen Patch/Update liegen aber nun mal sehr viele Stunden Tests, Abstimmungen mit Kunden sowie viel Schweiss und Blut.

Möchte noch hinzufügen: das ist IMHO keine Sicherheitslücke im WireGate-VPN! sondern eher eine optionale Optimierung für Paranoide (wie mich); für das OpenVPN im WireGate mit
- lokal beim Kunden mit HW-RNG generierten Keys
- individuellen X.509 Zertifikaten (jeder Kunde erhält vor Ort seine eigene PKI/CA! da bezahlen andere Zehntausende EUR für..)

Das wurde sauber designed (c) und hält eben auch mal 10J, selbst wenn eine Sache (hier SHA1) mal blöd fällt. Denn z.B. ohne den ta.key redet der Server garnicht mit dem "Angreifer", da kann der soviele SHA1-collisions errechnen wie er will, das Paket kommt da garnicht mehr auf dem Layer zur Prüfung an
Also um irgendwelche wissenschaftlichen Schwachstellen in SHA-1 überhaupt nutzen zu können, muss man ein Insider sein, der vorher Zugriff auf die Konfig hat/hatte.

Ergo, ist auch mit (trotz) SHA-1 immernoch 100x sicherer wie der Kindergarten-Kram ("VPN") in Fritzbox, DirectAccess & Co mit PreShared-Keys oder solchem quatsch
Da hilft auch AES256 und SHA512 nix, wenn die Authentisierung mist ist..
Entspannt lehnt man sich zurück, wenn es 9J später (das Zertifikat von wiregate1 läuft bald aus..) immernoch sauber und sicher ist..

-> Das funktioniert mit aktuellen Mainline-Releases aller mir bekannten OS immernoch problemlos ohne fummeln am Signatur-Algorithmus (natürlich wäre heute SHA256+ besser, aber: s.o.)..

Wer nun immernoch Sorgen hat, das die NSA, BND oder eine andere Organisation mit Millionen-Budget und massivem nun binnen weniger Monate(!?) eine SHA1-Kollision für eine Session errechnen kann, sollte sich lieber vertrauensvoll an seinen Lieblings-Kryptographie-Experten wenden..
Auch dafür gibts Lösungen, sprengt aber deutlich den Rahmen von Smarthome..
Für den Rest tuts das noch ein paar Jahre, bis die ersten WG in 5-10J platzen

Grüsse Makki

P.S.: OS/Distros(und Browser) die aufgrund religiöser Überzeugung alte, verbreitete Zöpfe mit Gewalt versuchen abzuschneiden finde ich übrigens auch ned so toll. Im Prinzip zwar richtig - aber eben nur im Prinzip, praktisch scheint Arch und/oder OpenSSL hier eine ziemlich Anwender-unfreundliche Strategie zu verfolgen. Sad..

[Shoko]

Anmerkung zum PS:
Ich habe natürlich keine Glaskugel, wie die anderen Distris damit umgehen werden, aber über kurz oder lang werden auch die nicht an OpenSSL 1.1 vorbeikommen. Arch Linux macht halt rolling releases so dass man damit immer recht aktuelle Softwarestände hat. In diesem Fall schlecht, weils mich jetzt als ersten erwischt.

Vielleicht machen andere Distris da irgendwelche Anpassungen an openssl 1.1 um auch md5 und sha1 noch zu erlauben, aber potentiell wird das Thema irgendwann auch für Benutzer anderer Linux Distributionen interessant.

Im Internet kursieren zwar Workarounds wie man OpenSSL 1.1 angeblich dazu bringt weiterhin mit SHA1 zusammenzuarbeiten, die habe ich aber zumindest mit OpenVPN nicht ans Laufen bekommen.

[makki]

P.P.S.: Naja, das Thema SHA1 ansich gehört natürlich mittelfristig "gelöst" nicht "geworkarounded", keine Diskussion..
Ich wollte damit nur sagen: so einfach war/ist es nicht, weil Henne/Ei-Problem.
Das es sicher keinen Hersteller gibt, der auch nur ansatzweise nach bis zu 9J diesen Support gibt..

Darf ich nicht im Detail sagen, aber ich hatte vor wenigen Wochen genau diese Diskussion (ganz ohne WG) über SHA1, RSA2048 für die CA - im VS-Umfeld, pipifein BSI-zertifiziert; ich sagte "neue Root-CA 2017 aufsetzen, mit SHA1, seid ihr "bekloppt"?" AW: "ja, hmm, dieser, jener und welcher Client kanns aber ned anders"
Meine Antwort dort: "ist mir wurscht, alles unter SHA256/AES256 bzw. , AES512-XTS (luks/Bitlocker) eskaliere ich ggfs. zum SiBe, StMi, oder Notfalls dem Geheimschutz-betreuenden BMWi und diskutiere das gerne mit dem BSI aus.
Auf einmal ging SHA256 dann doch nach zwei patches eine Woche später.

Nur spielen wir hier in einer anderen Liga, so krass ist es nicht, das wir uns an VSA orientieren müssen.
Ich schau mal, im Kern wiegesagt, kann das WG seit dem ersten Tag im Zweifel auch SHA256..

Eigentlich muss man nur ein kleines Script und eine Anleitung dazu schreiben.

Makki

[heckmannju]

Hi,
mann muss also nur was umkonfigurieren das es geht nix neues installieren?
VG
Jürgen

[makki]

Jep, eigentlich geht das (sha256 oder rmd160) seit jeher; da backported [das war pain-in-the-ass!] OpenSSL aufm WG ist topaktuell, alles gut..
Man muss es nur richtig einstellen in der .cnf, fertig..

Makki

[trant]

Hat diese Umstellung schon jemand probiert?

[makki]

Ja, ich Lief auf drei Systemen problemlos, man sollte halt nur schon halbwegs wissen, was man tut..
Über eine Step-by-Step-Anleitung (Putty herunterladen, öffnen, bash, rudimentäre (ba)sh Befehle, vi/nano/mcedit etc.pp. würde sich die Community sicher freuen)

Das löst übrigens auch gleich mal das Problem in einem anderen aktuellen Thread mit dem md5 der Self-Signed CA..

Man kann es aber eh kaum als "allgemeines Update" ausrollen, weil es für alle die glücklich sind das VPN aller Clients schrottet.

Makki

[trant]

makki, ich bin deinen Weg mal gegangen und habe die Zertifikate auf meinem Wiregate (Version 1.4.0) mal neu erstellt (SHA512), und es hat geklappt, denn ich kann mich auch mit der neuen OpenVPN for Android verbinden

Was ich gemacht habe:

1.) ein recreateCert.sh erstellt und ausgeführt (macht auch ein Backup von der aktuellen this-server-ca unter this-server-ca.saved)
2.) restart OpenVPN
3.) Clients neu erstellen und verteilen

Dieses Vorgehen hat bei mir funktioniert, heisst natürlich nicht, dass es auch bei euch funktionieren muss.

[StefanW]

Hallo Stefan,,

ich bin deinen Weg mal gegangen und habe die Zertifikate mal neu erstellt (SHA512), und es hat geklappt,

Glückwunsch.

Allerdings möchte ich darauf verweisen, dass der obige Post keine Anleitung im Sinne einer Schritt-zu-Schritt Anleitung ist und Makki hier rein als Privatperson spricht. Das ist keine offizielle Anleitung von WireGate und ungetestet! Wer das durchführt, tut das auf eigenes Risiko.

Wir bemühen uns um einen offiziellen Weg.

lg

Stefan

[trant]

Hallo Stefan,

selbstveständlich ist das auf eigenes Risiko. Da ich selbst Softwareentwickler bin, schien mir das Risiko für mich persönlich nicht sehr gross. Auch funktioniert das wiedereinspielen des Backups ohne Probleme und die alten Zertifikate funktionieren dann auch wieder.

[StefanW]

Alles gut, Stefan. Jeder darf mit seinem WireGate machen was er will und für richtig hält.

Es ist nur nicht jedem der Leser hier klar, dass Makki schon seit vier Jahren nicht bei bei WireGate ist und dass seine Ansichten und Ratschläge rein privater Natur sind und kein offizieller Ratschlag. Die produktiven Systeme von Makki laufen teils auf einem vier Jahre alten Softwarestand, daher ist beim Nachbau seiner Vor- und Ratschläge entsprechende Vorsicht walten zu lassen. Er hat das auch so geschrieben, aber vielleicht nicht für jeden deutlich genug.

Ich möchte nur vermeiden, dass sich jemand seine Kiste schießt und anschließend Support von uns verlangt, weil "Makki hat doch gesagt". Leider sind manche Kunden recht findig, wenn es darum geht einen Grund zu finden, warum der Supportfall keinesfalls auf ihre Rechnung gehen soll... Darum muss ich leider für die nötige Klarheit sorgen.

Ich bitte um Verständnis

Stefan