es gibt ein schulweites WLAN für „alle“. Der Zugriff kann einerseits über die Gruppe „wifi“ und das v7-WebUI aber andererseits zusätzlich über ein Voucher (z.B. für Gäste oder spontan erforderliche Zugriffe) gesteuert werden.
es gibt ein WPA3-Enterprise WLAN, in das nur Lehrergeräte gelangen. Da wird im Moment noch das snake-oil-Cert vom Server verwendet (10 Jahre gültig). Der Zugriff wird über die Gruppe „teachers“ realisiert.
Wenn ich das richtig sehe, kommen iPads damit klar aber Win11-Clients oder neuere Android-Clients nicht (mehr).
Daher nun folgende Fragen:
man soll offenbar kein öffentliches LE-Cert für den freeRADIUS Server nehmen sondern lieber ein selbst-signiertes Zertifikat. @tjordan hatte hier schon mal darauf hingewiesen. Nur aus Interesse: Warum soll man das nicht bzw ist es dramatisch, wenn man es doch macht? Ich frage deshalb, weil unser server eh schon ein gültiges LE-Cert hat. Das könnte ich mit wenigen Handgriffen dann auch immer passend für den freeRADIUS-Server verwenden. Zudem wird es hier auch so umgesetzt.
Mit WPA3 ist man in der Situation, dass alle Kollegen über ihre Credentials in das WLAN gelangen können und im Prinzip jedes Gerät mitbringen können, das sie wollen. Wenn nun aber die Credentials eines Kollegen versehentlich in Schülerhände geraten, ist das doch kaum oder gar nicht mehr aufspürbar, oder?
Normalerweise verbreiten sich solche Logins dann zwar rasant, so dass immer gleich sehr viele Geräte über einen Login angemeldet werden – aber das fällt unter Umständen gar nicht oder eher zufällig auf. Oder wie realisiert ihr das?
Im Unterschied zum PSK-WLAN hat man jetzt nur noch eine Hürde, um in das WLAN zu gelangen. WPA3-Enterprise ist zwar in großen Umgebungen besser zu managen aber die Hürde bis zur erfolgreichen Authentifizierung ist doch geringer als vorher – oder?
„Zwingt“ Ihr Eure KuK, regelmäßig eine neues Passwort zu setzen?
Das soll’s erstmal gewesen sein – über einen Austausch diesbzgl würde ich ich freuen.
Was hier beschrieben steht, ist nicht mehr Up-to-Date (Nachtrag: Ich würde die Quelle auch nicht unbedingt als Referenz betrachten nur weil ein Dienstleister (siehe Impressum) das so macht). Mittlerweile haben auch Androids genau wie Apple Geräte die Möglichkeit, das CA-Zertifikat bzw. Server-Zertifikat zu akzeptieren. Die Notwendigkeit, auf den Androids die CA händisch importieren zu müssen, ist weggefallen.
Stichwort: Organisationsvertrauen - Das Kernstück der RADIUS-Authentisierung.
Wenn du LE-Zertifikate verwendest, können alle Geräte, auf denen ebenfalls ein LE-Zertifikat, als Client-Zertifikat installiert ist sich mit der Methode EAP-TLS (zertifikatsbasierte Authentisierung) an deinem Funknetz anmelden, weil der RADIUS-Server auch dem Clientzertifikat vertraut, da beide aus der gleichen CA (LetsEncrypt) stammen. So könnte z.B. ein findiger Schüler sich irgendwie ein LE-Zertifikat beschaffen, dieses entsprechend konvertieren, auf sein Smartphone installieren und sich in deinem sicher geglaubten Lehrernetz über die zertifikatsbasierte Authentisierung anmelden. So wird die vermeintlich sichere, weil öffentliche, Zertifizierungsstelle zur Schwachstelle.
Die Frage die man sich dabei immer stellen muss: Wer vertraut hier wem warum?
Was bei Webservern oder sonstigen „öffentlichen“ Diensten (z.B. IMAPS, SSL-VPN) gut funktioniert, muss nicht auch in allen anderen Bereichen (Authentisierung bei der Einwahl in ein Firmennetzwerk) auch gut und richtig sein.
Irgendwie fehlt mir aber noch ein entscheidendes Puzzleteil, denn so wie ich das mit dem WPA3-WLAN bisher gesehen habe, wird das Zertifikat doch sowieso dem Client angeboten!?! Im Moment (da snake-oil), steht da bei der ersten Kontaktaufnahme zwar, dass es ein „unsicheres Zertifikat“ sei, aber es ist ja nicht so, dass man das Zertifikat zunächst auf das Gerät bringen müsste.
Wo ist der Denkfehler?
Viele Grüße,
Michael
bei der ersten Verbindung des Clients wird jedes Server-Zertifikat als unsicher eingestuft. Hintergrund ist, dass es auch ein Rogue-RADIUS sein könnte, der dazu dient, Passwörter auszuspähen. Daher sollte man immer das Zertifikat prüfen, bevor man es akzeptiert.
Ich gehe nicht davon aus, dass einer unserer Schüler einen eigenen FreeRADIUS Server betreiben geschweige denn zu Spionagezwecken einsetzen könnte. Dazu müsste ja auch einiges an Insiderwissen über den Aufbau der (Sub-) Netze bekannt sein. Aber klar: die Möglichkeit besteht — und man muss sich echt fragen, bis wohin man vertrauen soll und ab wann man paranoid wird, oder??
(Ein Rogue Accesspoint ist mMn einfacher)
Trotzdem ist mir eine Sache noch nicht klar: ob der Schüler nun das Zertifikat hat oder nicht: den Login des Lehrers hat er deswegen ja noch nicht. Ich nehme daher an, dass Du oben ein anderes Verfahren meinst, richtig?
Also wer das gültige cert hat, kommt auch rein? Sehe ich das richtig?? Das ist ja hier nicht so eingestellt…
nun die Frage war, warum nicht LE-Zertifikat als Server-Zertifikat für RADIUS. Antwort: Weil jeder sich ein LE-Zertifikat beschaffen, und damit bei der Zugangsprüfung zum Funknetz die Notwendigkeit der Eingabe von Benutzername und Kennwort und damit einhergehender Überprüfung irgendeiner Gruppenzugehörigkeit umgehen kann. Jeder mit einem LE Zertfikat kann sich dann dem WLAN verbinden und das würde ich als potentiell ziemlich unerwünscht einstufen.
Ok – der erste Teil ist schon klar … aber beim zweiten Teil …
… habe ich weiterhin ein Verständnisproblem: Warum reicht das Cert aus, um den Login zu umgehen? Da übersehe ich irgendwie etwas – oder es liegt nur an unserem speziellen Setup, das wir mit ntlm_auth und der Gruppenzugehörigkeit zur Gruppe „teachers“ machen.
das liegt an der gewählten Authentisierungsmethode des wpa_supplicants auf dem Client. Man gibt einfach EAP-TLS (Zertifikatsbasierte Authentisierung) anstelle von EAP-PEAP (Benutzerauthentisierung) ein und schon prüft der RADIUS Zertifikat anstelle von Benutzername und Kennwort.
Jetzt ergibt das ganze plötzlich Sinn! Besten Dank für die Nachhilfestunde!
… nochmal nachgehakt (Lehrerkrankheit) : Das Verfahren kann ein User aber nicht einfach selbst umstellen, sondern das gibt der Server vor, oder? (Bei mir stand zumindest nichts zur Wahl, als ich mich verbunden habe.)
das Verfahren kann der Benutzer einstellen, sobald er ein Zertifikat installiert hat. Ist kein Zertifikat im Speicher, ist die Option nicht auswählbar. Warum auch?
Ich weiß nicht mehr genau wie die Reihenfolge beim ersten Verbinden war, aber dann dürfte die erste Verbindung nur in dieser Reihenfolge möglich sein, richtig?
1.) Zuerst werden die Credentials abgefragt
2.) erst dann wird das Cert ausgeliefert!
Das hatte ich nicht mehr genau auf dem Schirm – aber umgekehrt wäre es nach allem, was Du oben geschrieben hast, Quatsch, richtig?!
Dass man sich danach dann nur noch mit dem Zertifikat verbinden kann, ergibt „plötzlich“ auch Sinn .
Zuerst werden Zertifikate ausgetauscht, damit die weitere Übertragung von Daten verschlüsselt übertragen wird. Client Hello ↔ Server Hello. Der Server zeigt sein Zertifikat, der Client akzeptiert das.
Jetzt gehts verschlüsselt weiter.
Die Authentisierungsmethode wird abgefragt. Dann werden, abhängig von der gewählten Methode Client-Zertifikat (EAP-TLS) oder Benutzerdaten (EAP-PEAP) vom Client übermittelt.
Der Radius prüft das Zertifikat auf seine Gültigkeit bzw. die Benutzerdaten und gibt dann den Zugang frei oder blockt ihn wenn was nicht stimmt.
Entweder ist höchste Zeit für’s Wochenende oder ich habe einen Knoten im Kopf:
Wenn zuerst das Zertifkat kommt und Client & Server vertrauen sich bereits, warum ist dann (auch beim ersten Login) noch extra der Login notwendig, wenn doch die Methode EAP-TLS im Prinzip bereits erfolgreich war!? Oder gilt das beim ersten Login nicht?
Der Vergleich mit ssh und ssh-copy-id drängt sich ja geradezu auf… da läuft das mit dem pub.key-Verfahren ja ähnlich, aber vor dem Schlüsselaustausch steht da ein erfolgreicher (erster) Login.
die Idee dahinter ist, dass die Anmeldedaten über den sogenannten outer-tunnel verschlüsselt übertragen werden sollen.
Daher ist im ersten Schritt erforderlich, dass der Client dem Server vertraut. Hier kommt das Serverzertifikat ins Spiel. Der Client vertraut dem Server → es können Daten ausgetauscht werden.
Im nächsten Schritt zeigt dann bei der Methode EAP-TLS der Client sein Zertifikat vor. Der Server prüft, ist das Zertifikat gültig und ob er der Zertifizierungsstelle des Client-Zertifikats vertraut. Ist das der Fall (und wenn beide Zertifikate aus der gleichen CA stammen ist das der Normalfall), hat man eine zweiseitige Vertrauensstellung.
Ok. Verstanden.
Aber könnte es sein oder konfigurierbar sein, dass ab der Stelle „Im nächsten Schritt…“ beim ersten Verbinden nur EAP-PEAP klappt?
(Ansonsten sehe ich auch weiterhin nicht ein, warum überhaupt irgendwo Credentials notwendig sind, wenn alles von vorneherein über Zertifikate funktioniert?)
EAP-PEAP setzt EAP-TLS voraus. Also nein.
Warum macht man dann nicht immer EAP-TLS? Macht man z.B. wenn es um firmeneigene oder schuleigene, verwaltete Geräte geht, da man hier die Client-Zertifikate über eine eigene PKI über SCEP generieren und ausrollen lassen kann.
Warum macht man es bei BYOD in der Regel nicht? Weil sich die Benutzer selbst auf der PKI Zertifikate erstellen und diese selbst als Client-Zertifikate auf ihr Endgerät importieren müssten (ich kenne tatsächlich eine Schule bei der das gemacht wird).
In dem Fall ist die EAP-PEAP Methode mit Benutzername und Kennwort einfach praktikabler.
Funktioniert ja auch prima. Man muss nur einmal auf dem Client das Serverzertifikat akzeptieren und dass sollte eben aus einer eigenen privaten CA stammen und nicht aus einer öffentlichen CA aus den oben beschriebenen Gründen.
Was die Geheimhaltung angeht. Es gibt bei den Zertifikat auch immer den sog. private Key → der sollte geheim sein und wird auch nie vorgezeigt. Nur der jeweilige öffentliche Teil des Zertifikats wird vorgezeigt und ausgetauscht.
Die ca kann zertifkate ausstellen. Fuer jedes geraet das einloggen daef bekommt es ein individuelles zertifkat das auch zurueckgezogen werden kann.
Wenn man als ca aber ein LE zertifikat nimmt, dann kommt man einfach an zertifkate und kann sich dann ins wlan einloggen.
Es ist also nicht „ein“ geheimes zertifkat. Das geheime ist das eigene ca zertifkat und der schluessel dafuer das einem erlaubt zertifkate auszustellen.
Die zertifkate imminner und outer tunnel sind net dieselben.
Richtig?
angesehen. Da wird ja beschrieben, wie man sich ein eigenes Zertifkat ausstellen kann.
Da ich vor längerer Zeit dem Server ein OPNSense-LE-Zertifikat spendiert habe, scheint das auf unserem v7-Server nicht mehr 100% zu funktionieren, denn es passt etwas nicht zusammen
Die Datei Sep 14 2019 cakey.pem stammt von der Erstinstallation und ist daher noch das Original aber die Datei Jun 22 04:06 cacert.pem ist von der OPNSense und gehört daher zum LE-Cert.
Aus diesem Grund gelingt es mir auch nicht, dass ich mit dem Befehl openssl x509 -req -in radius.csr -CA /etc/linuxmuster/ssl/cacert.pem -CAkey /etc/linuxmuster/ssl/cakey.pem -CAcreateserial -out radius.pem -days 365 -sha512
ein neue Zertifikat anfordern kann.
Die Fehlermeldung war sinngemäß „mismatch“, was ich sogar einsehe!
Die Frage ist: Kann man das cacert.pem auf dem v7-Server unter /etc/linuxmuster/ssl neu erzeugen lassen, so dass es wieder zusammenpasst?
Das soll für heute aber auch reichen…
Viele Grüße,
Michael
.