Freeradius -> einige Clients machen Probleme

[mrserious]

Nabend zusammen,

ich betreibe Freeradius auf Debian stable mit einer EAP-TTLS-Konfiguration.
Wir nutzen Windows-10-Laptops, auf welchen ganz schlicht Benutzername+Passwort eingegeben wurde, damit können sie sich dann mit dem WLAN verbinden.
Das TLS-Zertifikat muss natürlich einmal händisch bestätigt werden.
Problematisch ist: Das funktioniert auf fast allen Clients (auch diverse Mobil-Betriebssysteme, Linux, Mac...) problemlos, aber einige der Windows-10-Maschinen werfen folgenden Fehler:

Code: Alles auswählen

Wed Jan 25 19:53:49 2017 : Auth: Login incorrect (TLS Alert read:fatal:unknown CA): [host/USER] (from client WLAN-Controller port 48 cli xx-xx-xx-xx-xx-xx)
Wed Jan 25 19:53:51 2017 : Error: TLS Alert read:fatal:unknown CA
Wed Jan 25 19:53:51 2017 : Error:     TLS_accept: failed in unknown state
Wed Jan 25 19:53:51 2017 : Error: rlm_eap: SSL error error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Wed Jan 25 19:53:51 2017 : Error: SSL: SSL_read failed inside of TLS (-1), TLS session fails.

Habt ihr eine Idee oder einen Ansatz für mich?

[wanne]

besorg dir ein Zertifikat von ner "vertrauneswürdigen" CA und mach PEAP.
IMHO TTLS nicht mit Windows 7 und Windows 8 (im Gegensatz zu Win8.1) da muss man sich erst Zusätze runteladen. Denke das wird für Windows 10, die von da geupdated wurden immer noch gelten.
Sonst würde ich eh eher auf WPA-PSK mit unterschiedlichen Passwörtern setzen das ist sicherer. (MSCHAPv2 ist kaputt. 40Bit-Crypt hat im aktuellen Jahrtausend nichts mehr zu suchen. Und GTC wird von Windows nicht unterstützt, obwohl die da wie an TTLS mit standartisiert haben) und problemfreier.
Ansonsten gibts noch EAP-PWD und verlinkte für die Windows Leute irgend eine Software die das kann.

[mrserious]

Moin!

wenn's nach mir ginge würde ja einfach auf EAP-TLS umgestellt. Aber das ist natürlich recht aufwändig und nicht gewünscht.
Ich geb dir recht mit mschapv2, aber das wird doch nur innerhalb des TLS-Tunnels genutzt? Also das PW geht doch trotzdem TLS-verschlüsselt zum Radius-Server?
Insofern find' ich das zu vernachlässigen.

Heißt also, wenn ich mir ein vertrauenswürdiges Cert besorge (oder meins auf den Clients installiere) ist mein Problem behoben?

Hier mal der PEAP/TTLS/mschap-Auszug der eap.conf:

Code: Alles auswählen

 ttls {
                        default_eap_type = md5
                        copy_request_to_tunnel = yes
                        use_tunneled_reply = yes
                        virtual_server = "inner-tunnel"
                }

                peap {
                        default_eap_type = mschapv2
                        copy_request_to_tunnel = yes
                        use_tunneled_reply = yes
                        virtual_server = "inner-tunnel"
                }

                mschapv2 {
                }

[wanne]

Also das PW geht doch trotzdem TLS-verschlüsselt zum Radius-Server?

Ja. Aber TLS hängt halt an seiner PKI. IM Web ist CN=domainname. Schon da ist die Validieren eher schlampig. Aber für WLAN gibts sowas gar nicht.
Prinzipiell kann feltel mit seinem (vertrauenswürdigen) Cert fürs Debianforum MITM spielen und den MSCHAPv2-Handshake (und allen Internettraffic) mitlesen. Insbesondere kann er auch schlicht jedes Passwort annehmen und dann mitlesen.
Es gibt da ein paar Gegenmastnahmen:

• Windows 10 pinnt den CN Mit dem Debianforum Cert kommt man dann zumindest ab der 2. Anmeldung keiner mehr durch. Problem bleibt, dass es kein festes Schema für CNs gibt. Ich kann also mal lustig zu einer anderen CA gehen und ein Cert für den gleichen CN beantragen. Mit einer ausreichend dummen Begründung wird sie mir das auch aushändigen, da ja auch die CAs keine ahnung haben welcher CN legitim zu welcher Person gehört. Prinzipiell können wir ja sogar rein zufällig den gleichen CN gewählt haben, ohne das irgendjemand davon weiß.
• Die meisten Linux-Clienten fragen nach der CA. Dann muss der Angreifer zur selben CA laufen. Nimmt man dann z.B. die Telekom,. die nicht an Privatpersonen raus gibt, muss der Angreifer wenigstens irgend einer Organistation angehören. (Im Zweifelsfall der seines Arbeitgebers.) Gedacht ist daas wohl so, dass man da seine eigene CA aufsetzt. (So wie du das wohl im Moment machst.) Dann ist das auch wirklich sicher. Nur muss man dann die CA-Cerst sicher auf alle Clienten bekommen. Außerdem will das Windows 8 gerade nicht…

[mrserious]

Danke für deine Erläuterungen, wanne!
Ich wundere mich immer wieder, wie schlecht das teilweise implementiert ist.
Habe heute mal sämtliche Zertifikate für ein paar Minuten ausgetauscht und manche Clients geben nichtmal ne Meldung raus, sondern senden fröhlich ihre Zugangsdaten an einen "fremden" Server.
Viele Android-Geräte machen das z.B. so.
Bei Windows 10 wird die eigene CA (Zertifikat NICHT auf dem client installiert, aber bei der ersten Anmeldung am WLAN mit einem Klick durchgewunken) mal anerkannt und mal nicht... einige Leute kommen wunderbar ins WLAN, bei anderen bricht es mal ab und mal nicht.

Werde nun eine eine neue CA inkl. aller Zertifikate generieren und diese auf den Clients installieren. Das alles in der Hoffnung, es laufe dann halbwegs rund.

[BenutzerGa4gooPh]

EAP-TTLS (Tunneled TLS)
Bei diesem EAP-Typ findet ein Ausgleich zwischen Sicherheit und Einrichtungskosten statt. Hier werden die client-seitigen Zertifikate mit veralteten Passwort-Authentifizierungsmethoden wie PAP, CHAP oder MSCHAPv2 ersetzt. Bei EAP-TTLS authentifizieren sich die Server mit einem Zertifikat und richten einen TLS-Tunnel ein, über den die Challenge an den Client erfolgt.

http://www.ip-insider.de/wlan-absicheru ... g-a-97972/
Für Authentifizierung des Servers ist das Zertifikat von dessen Zertifizierungsstelle (CA) / Stammzertifikat auf den Clients erforderlich. Die Authentifizierung muss nicht erfolgen, entsprechendes Häkchen im Network Manager weglassen. Windows analog.
http://kiezlan.de/wpa2-enterprise-ubuntu
http://deployingradius.com/documents/co ... n/eap.html

Zertifikatprüfung für WPA2 Enterprise kann man in Konfigs der Clients mittels wpasupplicant erzwingen:
https://www.nowiressecurity.com/configu ... tion-linux

Bei Gästen und Smartphones organisatorisch schlecht möglich, bei eigenen Clients besser EAP TLS mit CA- und Clientzertifikat. Für jeden Client ein Spezielles. Organisatorisch etwas komplizierter als EAP TTLS und User/PW im Verzeichnisdienst/Datenbank - was in den meisten Fällen genügt.

Eine schlechte Implementierung von EAP TTLS sehe ich nicht: Zertifikate auf Gäste-PCs und Smartphones bringen??? Eher überspringen, Username und Passwort. Ansonsten muss man die dort bereits eingetragen CAs nutzen. Dann muss der RADIUS allerdings ebenfalls ein Zertifikat einer dieser oeffentlichen CAs besitzen. Wanne schrieb das oben.

Im Eingangsbeitrag sehe ich übrigens TLS Fehler, keine TTLS ...
Sieht aus, als würde das Stammzertifikat (CA) des RADIUS im Windows Client fehlen - aber nachgefragt werden.
Freeradius kann man testweise sehr gespraechig gestalten:
Aufruf mit freeradius -X (vorher Service stoppen) sowie radtest etc aus freeradius-utils bzw freeradius-dbg
Oder: http://deployingradius.com/scripts/eapol_test/

Edit: Es ist mir heute zwar gelungen, selbst erstellte Zertifikate für die RADIUS CA und Client in Android5 zu importieren, jedoch werden keine Zertifikate in den WLAN-Einstellungen für WPA2 Enterprise EAP TLS angezeigt - nicht mal die voreingestellten. Der Netzwerkmanager von Jessie hatte keine Probleme, beliebiges Verzeichnis angebbar.