also LE für RADIUS kann man echt nicht bringen. Ich grad mal einen Test gemacht. Du kannst irgendein gültiges LE-Server-Zertifikat nehmen, dass mit openssl entsprechend konvertieren, auf deinen Wifi-Client importieren und ZACK kannst du dich in jedem Funknetz, in dem RADIUS mit LE-Zertifikaten läuft, mit der EAP-TLS Methode anmelden.
Und sooo wird eine vermeintlich sichere Sache zur Schwachstelle. Da kann man gleich Open-Wifi machen.
Viele Grüße
Thomas
P.S. Das kommt gleich nach ESX ins Internet stellen.
Eduroam als Organisationsverbund von Bildungs- und Forschungseinrichtungen betreibt eine große hierarchische RADIUS-Infrastruktur und hat deswegen das Thema auch und hat ein Konfigurationswerkzeug CAT (auf GitHub) geschaffen. Auf dieser Basis wurde https://enterprise-wifi.net geschaffen, dass für Einrichtungen gedacht ist, die nicht an Eduroam teilnehmen. Damit könnte den Nutzern ein einfaches Tools an die Hand gegeben werden, dass er nur noch ausführen muss um sein Endgerät korrekt zu konfigurieren. Hat das schonmal jemand ausprobiert?
Das ist so nicht ganz korrekt, weil zur vollständigen korrekten Einrichtung des WLAN-Profils gehört es auch den CN des Zertifikats (= DNS-Namen) des RADIUS-Servers mit anzugeben und den Zertifikatsinhaber kann es nur einmal geben. Das ist aber je nach Betriebssystem mal mehr und mal noch mehr kompliziert, weswegen es bei Eduroam das CAT gibt.
leider nein. Radius prüft, ob die CA des Serverzertifikats mit der des Client-Zertifikats übereinstimmt und ob das Zertifikat gültig ist. Die Identität muss mit dem CN des Client-Zertifikat überein stimmen.
die Fehlermeldung sieht bei mir so aus:
(20) eap_tls: Continuing EAP-TLS
(20) eap_tls: Got final TLS record fragment (331 bytes)
(20) eap_tls: [eaptls verify] = ok
(20) eap_tls: Done initial handshake
(20) eap_tls: TLS_accept: SSLv3/TLS write server done
(20) eap_tls: <<< recv TLS 1.2 [length 0531]
(20) eap_tls: TLS - Creating attributes from certificate OIDs
(20) eap_tls: TLS-Client-Cert-Serial := „035db955aac90964d945f1f1fd94857d2713“
(20) eap_tls: TLS-Client-Cert-Expiration := „230507084738Z“
(20) eap_tls: TLS-Client-Cert-Valid-Since := „230206084739Z“
(20) eap_tls: TLS-Client-Cert-Issuer := „/C=US/O=Let’s Encrypt/CN=R3“
(15) eap_tls: ERROR: SSL says error 20 : unable to get local issuer certificate
(15) eap_tls: >>> send TLS 1.2 [length 0002]
(15) eap_tls: ERROR: TLS Alert write:fatal:unknown CA
tls: TLS_accept: Error in error
(15) eap_tls: ERROR: Failed in FUNCTION (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed
(15) eap_tls: ERROR: System call (I/O) error (-1)
(15) eap_tls: ERROR: TLS receive handshake failed during operation
(15) eap_tls: ERROR: [eaptls process] = fail
(15) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed
(15) eap: Sending EAP Failure (code 4) ID 167 length 4
Heißt: Mein RADIUS kennt die CA des Zertifikats nicht, weil mein RADIUS eine eigene CA verwendet und eben nicht die von LetsEncrpyt. Wäre es die gleiche CA, wäre er Zugriff gelungen.
Am Besten wäre eine in die Schulkonsole integrierte PKI bei linuxmuster.net mit SCEP für Client-Zertifikate und User-Certs on Demand. Dann wäre die Lösung fast nicht mehr zu toppen…
ich rede von der Zertifikatprüfung, die der Client ausführen muss, bevor er seine Zugangsdaten (egal ob PEAP mit Benutzername/Passwort oder EAP-TLS mit Clientzertifikat) an irgendeinen RADIUS-Server sendet. Der Client muss ja erstmal sicherstellen, dass er auch mit dem richtigen für das WLAN-zuständigen RADIUS-Server spricht. Die Überprüfung muss aber leider beim privaten Endgerät der Nutzer selbst konfigurieren und die dafür notwendigen Info kann er nur von seinem WLAN-Betreiber erhalten und der kennt aber wiederum nicht alle möglichen Endgeräte und Abweichungen an Konfigurationsdialogen in den Betriebssystemversionen. Deswegen entstand auch das Configuration Assistant Tool.
Dass der RADIUS-Server alle Zertifikate von LE akzeptieren muss, wenn man LE für seine Clientzertifikate nutzt, das ist klar, aber das macht ja hoffentlich niemand aus den Gründen, wo wir uns einig sind.
Ich bin jetzt nicht genau der radius experte also bitte korrigeiren wennnich was falsch im kopf habe.
Aber, ichndachte das ist so, dass man eine eigene ca und den key braucht dass man uberhaupt client zertifikate erzeugen oder wieder zurueckziehen kann.
Wenn ich eine fremde ca verwenden moechte (LE) kann ich ja keine zertifikate erzeugen weil der key wohlbehuetet bei letsencrypt liegt. es handelt sich ja beim wlan um private netzwerke. Da sind die geraete nicht mit domainadresse im internet so auf die da letsencrypt zertifikate ausstellen wuerde.
kein Endgerät spricht direkt mit dem RADIUS-Server, daher kann man im WPA-Supplicant auch nicht direkt einen RADIUS-Server auswählen. Der Client sendet sein Authentisierungsanfrage an irgendeinen AP. Dieser AP (oder irgendein Proxy wenn man die Netzlast verringern will) spricht dann mit dem für dieses Funknetz zuständigen RADIUS-Server und fragt: Hier hab hier ein Gerät, das kommt mit den und den Daten daher, darf der rein? Der RADIUS sagt dann, jo passt, lass durch oder Nein, der darf nicht, der kommt mit einem Zertifikat daher, dessen Zertifizierungsstelle ich nicht kenne, oder ich hab die Anmeldedaten geprüft, entweder stimmt Benutzername oder Kennwort nicht.
Der RADIUS-Server ist über die Einstellungen des Funknetzes definiert. Kein Client darf den frei wählen, daher kann man das auch nicht konfigurieren. Auch über irgendein Tool nicht.
ganz Recht, der CA-Key zum Signieren liegt bei der Zertifizierungsstelle, aber wenn du z.B. über certbot ein Zertifikat bei LetsEncrypt anforderst bekommt man ein Serverzertifikat mit dazugehörigem pivatekey. Die liegen i.d.R. unter /etc/letsencrypt/ssl/live/name.der.webseite.
Die kann man mit openssl so exportieren, dass daraus ein p12-Zertifikat wird, das man auf Endgeräten als Clientzertifikate importieren kann.
Man braucht nur Zugriff auf irgendeinen Server, der sich LE-Zertifikate holt.
ich schrieb auch nicht von einer freien Wahl des RADIUS-Servers, sondern von der Überprüfung des korrekten Kommunikationspartners und dass dieser vom WLAN-Betreiber vorgegeben ist. Natürlich reichen die Endgeräte ihre Zugangsdaten nur an den AP und der leitet die Nachricht weiter, dennoch muss das Endgerät prüfen, ob am anderen Ende der korrekte Server kommuniziert.
Dort kann ich sehr wohl einstellen, dass wenn der falsche RADIUS-Server „antwortet“, weil es ein AP oder RADIUS-Server eines MITM-Angreifers ist, mein Endgerät dann keine Daten übermittelt.
(Hervorhebung von mir)
Warum sollte man so einen Unfug machen? Dann kann man ja nie einzelne Clients unterscheiden, geschweige denn durch Widerruf des Zertifikats sperren.
jetzt verstehe ich, was du meinst. Die Einstellung ist aber an sich dafür da um zu verhindern, dass der Client andere Zertifikate als die einer bestimmten Zertifizierungsstelle für diese WiFi-Verbindung verwendet werden soll, z.B. wenn ich vorher eigens eine CA importiert habe aus der mein Client-Zertifikat stammt. Also kurz: ich sage dem Client: Verwende für diese Verbindung ein Zertifikat aus dieser Zertifizierungsstelle und nicht eins, was zufällig sonst noch in deinem Zertifikatsspeicher rumtobt aber aus einer anderen CA stammt.
Damit kann man, wie du ganz richtig sagst, Clientseitig verhindern, dass Daten an einen Rogue-RADIUS abfließen.
Das war aber gar nicht das Thema. Thema ist, ich kann mit irgendeinem LE-Zertifikat mit EAP-TLS auf meinem Smartphone einem Funknetz beitreten, das serverseitig ebenfalls mit LE-Zertifikaten arbeitet, weil beide Zertifikate aus der gleichen CA stammen und deswegen RADIUS mit LE-Zertifikaten Mist in der Kategorie „ESX im Internet veröffentlichen“ ist.
und jetzt verstehe ich dein Problem besser. Ja das liegt dann im Aufgabenbereich des RADIUS-Serverbetreibers. Wenn er die Wahl trifft eine weitverbreitet genutzte Zertifizierungsstelle für seine Clientzertifikate zu nutzen, dann kann und darf er sich nicht darauf verlassen, dass irgendein Zertifikat dieser Zertifizierungsstelle ausreicht. Er muss im RADIUS-Server seine Richtlinien zur Überprüfung des Clientzertifikats dann so einstellen, dass Details des Zertifikats geprüft werden und nicht nur der Zertifizierungsstelle vertraut wird.
Hier könnte dann das Problem auftreten, dass LE keine zusätzlichen Details in Zertifikatanträgen zulässt und man sich ausschließlich auf Validierung von DNS-Einträgen beschränken kann.
Die Aussage trifft auf den kleinen Rahmen oben in meinem Screenshot zu. Der untere Rahmen/Teil im Bild bezieht sich ausschließlich auf die Validierung des Zertifikats des RADIUS-Servers.
für RADIUS mit Authentifizierungmethode EAP-TLS (Clientzertifikate) gebe ich dir vollkommen recht.
Beim Serverzertifikat kann das schon sinnvoll sein, z. B. wenn BYOD ein Thema ist und man keine administrative Hoheit über alle eingesetzten WLAN-Clients hat. Dann hat man die Wahl alle Nutzer das Serverzertifikat auf ihrem Gerät importieren zu lassen oder man hat ein Serverzertifikat, dass von einer weit verbreiteten vorinstallierten Zertifizierungsstelle signiert ist. So oder so geht man immer durch die Supporthölle, wenn man fremde Geräte im WLAN hat.
so ganz verstehe ich das alles noch nicht, leider kenne ich mich mit Radius nicht wirklich gut aus.
Was mir nicht klar ist: Wieso soll es ein Problem sein, wenn ein Serverzertifikat z. B. von LE signiert ist? Der Server wird ja deshalb nicht gleich alle Client-Zertifikate akzeptieren, die mit irgendeinem anderen LE_Zertifikat generiert wurden. Der Server sollte doch nur Client-Zertifikate akzeptieren, die er selbst generiert (bzw. signiert) hat - mit seinem Zertifikat, das nur er hat.
Und überhaupt: Ich will ja gar keine Client-Zertifikate. Ich stelle mir das so vor: Erforderlich sind zwei Schritte:
Der Server weist nach, dass er wirklich der ist, der er behauptet, damit niemand seine geheimen Zugangsdaten irgendeinem fremden AP anvertraut.
Der Client weist nach, dass er das WLAN nutzen darf.
Im ersten Schritt reicht es doch vollkommen, wenn der Server ein (LE-)Zertifikat mit der Domain der Schulhomepage vorzeigt. Dann weiß der User (wenn er die Domain der Homepage kennt), dass er mit dem richtigen Server spricht.
Im zweiten Schritt kommen Username und Passwort zum Zug.
das Problem an der Sache ist die gemeinsame CA. Der RADIUS-Server vertraut jedem Zertifikat, das aus der gleichen CA stammt und gültig ist. Es ist vollkommen unerheblich ob du Client-Zertifikate machen willst oder nicht. Irgendjemand kann sich die Zertifikate, z.B. aus seiner privaten Nextcloud mit LE-Zertifikaten, schnappen und diese als Client-Zertifikat auf sein Endgerät importieren. Dann geht er in dein Funknetz und wählt nicht PEAP sondern TLS als Methode aus und wählt das Client-Zertifikat das LE-Zert seiner privaten Nextcloud. RADIUS prüft das Zertifikat und sagt: Prima, mein Serverzertifikat und das Zertifikat des anfragenden Clients stammen aus der gleichen CA, ist zeitlich gültig und somit vertrauenswürdig → ok
Und schon könnt ihr Clients im Netz haben, von denen ihr nicht mal zu träumen wagtet.
Stichwort: Organisationsvertrauen
So praktisch LE bei Webservern sein kann. Finger weg davon bei RADIUS. RADIUS ist kein Webserver und auch nicht vergleichbar.
Viele Grüße
Thomas
PS: Den Dialog könnt ihr euch so vorstellen:
Client: Hi! Ich will rein!
Server: Hi! Guck mal! Ich hab 'nen gültigen Ausweis von LetsEncrypt!
Client: Klasse! LetsEncrpyt kenn ich! Guck mal, ich hab auch einen gültigen Ausweis von LetsEncrypt!
Server: Super! LetsEncrypt kenn ich auch! Komm rein!
und sooo schwierig ist das bei freeradius nun nicht mit den eigenen Zertifikaten.
Unter /etc/freeradius/3.2/certs liegen i.d.R cnf- Dateien, Vorlagen zum Generieren von CA, Server und Client-Zertifikaten → einmal richtig ausfüllen → make → mods-enabled/eap anpassen → fertig
Und Stichwort BYOD → da würd ich mir zweimal überlegen, ob ich solche potentiell verseuchten Geräte in ein mit WPA/2/3-Enterprise abgesichertes Netz aufnehme, wo evtl. sensible Daten liegen, oder die doch lieber in einem Gast-Netz mit CaptivePortal unterbringe
danke für Deine ganzen Erklärungen - so langsam verstehe ich das Problem: „Der RADIUS-Server vertraut jedem Zertifikat, das aus der gleichen CA stammt.“ Das ist für die Situation, dass der Server seine eigene CA ist, und sicher ganz viele Szenarien natürlich sinnvoll. Für ein WLAN mit BYOD bedeutet das aber, dass man immer die CA auf den Endgeräten bekannt machen oder ihr „irgendwie“ vertrauen muss.
Das Problem ist ja nicht, eine eigene CA zu basteln - das geht recht einfach. Das Problem ist, dass sich die User dann nicht einfach so anmelden können.
Einsatzzweck wäre ein WLAN ohne (ungesicherten) Zugriff auf Schulnetz. Dort soll man auch BYOD-Geräte verwenden können. Da wäre es schon schön, wenn das mit Radius so ginge, dass die Clients dem Radius automatisch vertrauen, weil er ein gültiges und von einer vertrauenswürdigen CA signiertes Zertifikat für eine bekannte Domäne vorzeigt. Aber wenn ich die Diskussion richtig verstehe, dann ist das bei Radius nicht vorgesehen.
vielen Dank für eure Diskussion: so langsam wird mir das alles klarer.
das Problem an der Sache ist die gemeinsame CA. Der RADIUS-Server
vertraut jedem Zertifikat, das aus der gleichen CA stammt und gültig
ist. Es ist vollkommen unerheblich ob du Client-Zertifikate machen
willst oder nicht. Irgendjemand kann sich die Zertifikate, z.B. aus
seiner privaten Nextcloud mit LE-Zertifikaten, schnappen und diese als
Client-Zertifikat auf sein Endgerät importieren. Dann geht er in dein
Funknetz und wählt nicht PEAP sondern TLS als Methode aus und wählt das
Client-Zertifikat das LE-Zert seiner privaten Nextcloud. RADIUS prüft
das Zertifikat und sagt: Prima, mein Serverzertifikat und das Zertifikat
des anfragenden Clients stammen aus der gleichen CA, ist zeitlich gültig
und somit vertrauenswürdig → ok
Und schon könnt ihr Clients im Netz haben, von denen ihr nicht mal zu
träumen wagtet.
… jetzt hab ich das auch endlich mal verstanden: also woher das "keine
öffentlichen Zertifikate im Radius kommt.
Das mit der eigenen CA ist auch echt kein Hexenwerk: steht auch hier im
Forum wie das geht (danach hab ich es auch eingerichtet).
Und jetzt wo Android die Möglichkeit hat beim ersten Kontakt der CA zu
vertrauen ist ja alles wieder gut
