Problem mit WLAN Client und WPA2 Enterprise EAP-TLS

[geppi]

In einem WLAN mit WPA2 Enterprise EAP-TLS und entsprechender Authentifizierung über Zertifikate habe ich ein Problem mit einem Client den ich nicht verbunden bekomme. Andere Clients verbinden sich erfolgreich und bei diesen sieht der Trace z.B. folgendermaßen aus.

Code: Alles auswählen

[RADIUS-Server] 2026/01/24 20:00:44,849  Devicetime: 2026/01/24 20:00:45,083
Received RADIUS Authentication Request request 101 from client X:
-->client matches static IPv4 table entry X
-->known attributes of request:
.......
   EAP-Message:
   (232 bytes)
   -->EAP Header
   EAP Packet Code     : Response
   EAP Packet Id       : 2
   EAP Packet Len      : 232
   EAP Packet Type     : TLS
   --> EAP/TLS Packet
   TLS Flags           :
   --> SSL/TLS Record
   Record Content Type : Handshake
   Record Length       : 221
   Protocol Version    : TLSv1
   Handshake Msg Type  : Client Hello
   Message Length      : 217
   -->SSL/TLS Client Hello
   Protocol Version    : TLSv1.2
   Client Random       : 44 19 6b bc 4c f1 97 f2 D.k.L...
                         9d 99 68 cf 61 8d 31 a2 ..h.a.1.
                         ed d3 e4 da 9b 99 b9 c4 ........
                         30 f6 11 b9 f9 9c 3c 6d 0.....<m
   Session ID          : 77 a5 05 d8 1a 80 61 b6 w.....a.
                         a7 31 56 6c 94 92 1a 96 .1Vl....
                         08 16 4e 59 31 8f c8 0c ..NY1...
                         9e 30 e6 16 cb 54 6b 45 .0...TkE
   Cipher Suites       : TLS_AES_128_GCM_SHA256
                         TLS_AES_256_GCM_SHA384
                         TLS_CHACHA20_POLY1305_SHA256
                         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
                         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
                         TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
                         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
                         TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
                         TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
                         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
                         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
                         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
                         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
                         TLS_RSA_WITH_AES_128_GCM_SHA256
                         TLS_RSA_WITH_AES_256_GCM_SHA384
                         TLS_RSA_WITH_AES_128_CBC_SHA
                         TLS_RSA_WITH_AES_256_CBC_SHA
                         TLS_RSA_WITH_3DES_EDE_CBC_SHA
   Compression Methods : NULL
   Ext. Master Secret  :
   Reneg. Info         :
   Supported Groups    : ecdh_x25519
                         secp256r1
                         secp384r1
   EC-Point Formats    : uncompressed
   Sign. Algorithms    : ecdsa_secp256r1_sha256
                         rsa_pss_rsae_sha256
                         rsa_pkcs1_sha256
                         ecdsa_secp384r1_sha384
                         rsa_pss_rsae_sha384
                         rsa_pkcs1_sha384
                         rsa_pss_rsae_sha512
                         rsa_pkcs1_sha512
                         rsa_pkcs1_sha1
   Keyshare            :
    ecdh_x25519        : 34 be 47 84 bd 2f bc 69 4.G../.i
                         1f 4b 64 b0 bf 92 77 e7 .Kd...w.
                         04 4b f1 a1 62 4b 12 ce .K..bK..
                         65 97 6d da 60 9e 22 26 e.m.`."&
   PSK Exchange Modes  : psk_dhe_ke
   Supp. Versions      : TLSv1.3
                         TLSv1.2
   Mobility-Domain-Id  : 55370
   WLAN-Pairwise-Cipher: TGI-CSE-CCMP128
   WLAN-Group-Cipher   : TGI-CSE-CCMP128
   WLAN-AKM-Suite      : TGI-AUTHSE-8021X-FT
   WLAN-Group-Mgmt-Cipher: TGI-CSE-BIPCMAC128
   WLAN-RF-Band        : 2.4-GHz
-->user name contains no realm, using empty realm
-->realm of user is ''
-->authenticating locally
-->found user 'sirius.ofc.digitx.de' in database(s)
-->authenticating via EAP
-->queueing request for later response

Worauf im Trace später folgendes steht.

Code: Alles auswählen

[TLS] 2026/01/24 20:00:44,849  Devicetime: 2026/01/24 20:00:45,084
Receiving Client Hello on connection 184684:
-> parsing TLS extensions
-> protocol version is TLSv1.2
-> selected x25519 as named group
-> enable extended master secret usage
-> created new session id
-> select cipher:
 -> check cipher TLS_AES_128_GCM_SHA256
  -> not allowed for selected protocol version
 -> check cipher TLS_AES_256_GCM_SHA384
  -> not allowed for selected protocol version
 -> check cipher TLS_CHACHA20_POLY1305_SHA256
  -> encryption algorithm disallowed by config
 -> check cipher TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  -> server key type mismatch
 -> check cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 -> PFS suite or no PFS preference, selection done
-> selected cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-> selected signature scheme is rsa_pkcs1_sha256
-> selected elliptic curve is x25519
-> selected elliptic curve point format is uncompressed
-> client supports secure renegotiation (by extension), enable it
-> all fine, ready to send Server Hello

Bei dem Client den ich nicht verbunden bekomme sieht es folgendermaßen aus.

Code: Alles auswählen

[RADIUS-Server] 2026/01/24 19:55:30,484  Devicetime: 2026/01/24 19:55:30,710
Received RADIUS Authentication Request request 93 from client X:
-->client matches static IPv4 table entry X
-->known attributes of request:
.......
   EAP-Message:
   (203 bytes)
   -->EAP Header
   EAP Packet Code     : Response
   EAP Packet Id       : 2
   EAP Packet Len      : 203
   EAP Packet Type     : TLS
   --> EAP/TLS Packet
   TLS Flags           :
   --> SSL/TLS Record
   Record Content Type : Handshake
   Record Length       : 192
   Protocol Version    : TLSv1
   Handshake Msg Type  : Client Hello
   Message Length      : 188
   -->SSL/TLS Client Hello
   Protocol Version    : TLSv1.2
   Client Random       : b3 0c 54 b6 6f 0b 7d 1c ..T.o.}.
                         69 ab a0 42 f6 77 69 34 i..B.wi4
                         d1 47 11 2f e2 0c 7e 05 .G./..~.
                         d6 ca bd e7 5a 53 5a 3e ....ZSZ>
   Cipher Suites       : TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
                         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
                         TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
                         TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
                         TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
                         TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
                         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
                         TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
                         TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
                         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
                         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
                         TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
                         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
                         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
                         TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
                         TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
                         TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
                         TLS_DHE_RSA_WITH_AES_256_CBC_SHA
                         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
                         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
                         TLS_DHE_RSA_WITH_AES_128_CBC_SHA
                         TLS_RSA_WITH_AES_256_GCM_SHA384
                         TLS_RSA_WITH_AES_128_GCM_SHA256
                         TLS_RSA_WITH_AES_256_CBC_SHA256
                         TLS_RSA_WITH_AES_128_CBC_SHA256
                         TLS_RSA_WITH_AES_256_CBC_SHA
                         TLS_RSA_WITH_AES_128_CBC_SHA
   Compression Methods : NULL
   Reneg. Info         :
   EC-Point Formats    : uncompressed
   Supported Groups    : ecdh_x25519
                         secp256r1
                         ecdh_x448
                         secp384r1
                         secp521r1
   Encrypt-Then-MAC    :
   Ext. Master Secret  :
   Sign. Algorithms    : 0x0905
                         0x0906
                         0x0904
                         ecdsa_secp256r1_sha256
                         ecdsa_secp384r1_sha384
                         ecdsa_secp521r1_sha384
                         ed25519
                         ed448
                         0x081a
                         0x081b
                         0x081c
                         rsa_pss_pss_sha256
                         rsa_pss_pss_sha384
                         rsa_pss_pss_sha512
                         rsa_pss_rsae_sha256
                         rsa_pss_rsae_sha384
                         rsa_pss_rsae_sha512
                         rsa_pkcs1_sha256
                         rsa_pkcs1_sha384
                         rsa_pkcs1_sha512
                         ecdsa_sha224
                         rsa_pkcs1_sha224
                         dsa_sha224
                         dsa_sha256
                         dsa_sha384
                         dsa_sha512
   WLAN-Pairwise-Cipher: TGI-CSE-CCMP128
   WLAN-Group-Cipher   : TGI-CSE-CCMP128
   WLAN-AKM-Suite      : TGI-AUTHSE-8021X-SHA256
   WLAN-Group-Mgmt-Cipher: TGI-CSE-BIPCMAC128
   WLAN-RF-Band        : 2.4-GHz
-->user name contains no realm, using empty realm
-->realm of user is ''
-->authenticating locally
-->found user 'skye.ofc.digitx.de' in database(s)
-->authenticating via EAP
-->queueing request for later response

Worauf im Trace folgendes zum Scheitern der Verbindung steht.

Code: Alles auswählen

[TLS] 2026/01/24 19:55:30,486  Devicetime: 2026/01/24 19:55:30,711
Receiving Client Hello on connection 184667:
-> parsing TLS extensions
-> protocol version is TLSv1.2
-> selected secp521r1 as named group
-> enable extended master secret usage
-> created new session id
-> select cipher:
 -> check cipher TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  -> server key type mismatch
 -> check cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  -> no fitting signature/hash algorithm
 -> check cipher TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  -> no fitting signature/hash algorithm
 -> check cipher TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  -> server key type mismatch
 -> check cipher TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  -> encryption algorithm disallowed by config
 -> check cipher TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  -> encryption algorithm disallowed by config
 -> check cipher TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  -> server key type mismatch
 -> check cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  -> no fitting signature/hash algorithm
 -> check cipher TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  -> no fitting signature/hash algorithm
 -> check cipher TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  -> server key type mismatch
 -> check cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  -> no fitting signature/hash algorithm
 -> check cipher TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  -> no fitting signature/hash algorithm
 -> check cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  -> server key type mismatch
 -> check cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  -> no fitting signature/hash algorithm
 -> check cipher TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  -> no fitting signature/hash algorithm
 -> check cipher TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  -> server key type mismatch
 -> check cipher TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  -> no fitting signature/hash algorithm
 -> check cipher TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  -> no fitting signature/hash algorithm
 -> check cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  -> server key type mismatch
 -> check cipher TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  -> no fitting signature/hash algorithm
 -> check cipher TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  -> no fitting signature/hash algorithm
 -> check cipher TLS_RSA_WITH_AES_256_GCM_SHA384
  -> no fitting signature/hash algorithm
 -> check cipher TLS_RSA_WITH_AES_128_GCM_SHA256
  -> no fitting signature/hash algorithm
 -> check cipher TLS_RSA_WITH_AES_256_CBC_SHA256
  -> no fitting signature/hash algorithm
 -> check cipher TLS_RSA_WITH_AES_128_CBC_SHA256
  -> no fitting signature/hash algorithm
 -> check cipher TLS_RSA_WITH_AES_256_CBC_SHA
  -> no fitting signature/hash algorithm
 -> check cipher TLS_RSA_WITH_AES_128_CBC_SHA
  -> no fitting signature/hash algorithm
-> cannot select cipher suite, exiting

Ich verstehe nicht warum hier z.B. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 scheitert, obwohl der Client dieses ja angeboten hat und auch den Signatur Algorythmus rsa_pkcs1_sha256 anbietet. Oder interpretiere ich das 'no fitting signature/hash algorithm' falsch?

Die Zertifikate sind alle mit dem identischen Verfahren erzeugt worden. In den Client Zertifikaten und im CA Zertifikat steht 'Signature Algorithm: sha256WithRSAEncryption'.

[Dr.Einstein]

Der Client ist halt moderner und mag den alten Krempel nicht. Erhöhe also die Verschlüsselungsverfahren vom RADIUS-Server und/oder vom Serverzertifikat.

[geppi]

Ich kann Deine Antwort noch nicht so ganz einordnen.

Der Client bietet im obigen Handshake doch das "alter Krempel" Verschlüsselungsverfahren TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 an und ebenso den Signaturalgorythmus rsa_pkcs1_sha256.

Dem Trace nach weist auch der Server die Authentifizierungsanfrage zurück und nicht der Client.

Was mir nach Deiner Bemerkung aber aufgefallen ist, ist dass die vom Client angebotenen Ciphers die neuen PQC Algorithmen 0x0905, 0x0906, 0x0904, 0x081a, 0x081b und 0x081c enthalten. Die kennt der Lancom noch nicht mal mit Namen. Könnte es sein, dass der Lancom RADIUS Server sich daran "verschluckt" und den erst an 18. Stelle aufgeführten, passenden Signaturalgorithmus deshalb nicht erkennt?

Mal abgesehen davon, kann man denn bei einem LCOS 10.80 die Verschlüsselungsverfahren des RADIUS-Servers erhöhen und wie?

[Dr.Einstein]

Mal abgesehen davon, kann man denn bei einem LCOS 10.80 die Verschlüsselungsverfahren des RADIUS-Servers erhöhen und wie?

/Setup/RADIUS/Server/EAP/EAP-TLS

Ich habe ein wenig die Sorge, dass der Lancom bei Radius ähnlich wie bei VPN-IKEv2 sich intern Cipher-Suites zusammensetzt, und nicht die einzelnen Protokolle Schritt für Schritt durchgeht und abgleicht. Im IKEv2-Trace sieht man das schön, dass bestimmte Kombinationen abgelehnt werden, obwohl diese bei der Enc.-Tabelle angehakt sind. Und die klassische RSA-Kombination ist in der Auflistung des Clients sehr sehr weit unten ... Bin gespannt, was einer der Entwickler zu sagt. Könnte auch sein, dass der Lancom ein Keyshare erwartet bei secp. Kannst du testweise mal Prefer PFS am Lancom deaktivieren?

[geppi]

Ahh, danke. Ich vergesse leider immer wieder wo im Lancom man was setzt. Hab halt nicht täglich damit zu tun.
Aber da war ich schon mal dran: 'Prefer PFS' ist schon an.

So sehen meine Einstellungen zu EAP-TLS aus:

Screenshot_20260125_230106.png

Da ist bei den Verschlüsselungsverfahren eigentlich eh schon alles gesetzt, bis auf Cacha20-Poly1305.

Ich hab inzwischen zwar eine Möglichkeit gefunden die angebotenen 'Cipher Suites' vorzugeben, aber leider noch nichts, um auf Client Seite die Signatur-Algorithmen einzuschränken.

Bin auch mal gespannt ob es dazu noch einen Kommentar von Entwicklungsseite geben wird.

Das ganze ist super ärgerlich, weil der Client in der Vergangenheit mit genau diesen Zertifikaten funktioniert hat.
Das war unter Ubuntu. Jetzt ist er mit Arch Linux aufgesetzt und ich vermute mal, dass dabei die neuesten Versionen von wpa_supplicant und openssl zum Einsatz kommen. Sieht so aus, als würde mein inzwischen etwas betagter Lancom 1781VA von der Anzahl an dazugekommenen Verschlüsselungsverfahren überrollt.

[Dr.Einstein]

Nimm mal bitte secp521r1 raus aus deiner RADIUS-Liste und prüfe erneut. Wenn er dann einen kleineren Algorithmus vom secp nimmt, diese auch entfernen.

[GrandDixence]

Und die Kryptografie-Einstellungen an die Empfehlungen vom BSI TR-02102-2 anpassen:
https://www.bsi.bund.de/DE/Themen/Unter ... _node.html

MD5, 3DES, RC4, SHA-1, TLS 1.1?! In welchem Jahrzehnt lebt dieser Netzwerktechniker:in?

Bei ordentlichen Linux-Distributionen kann mit dem "crypto_policies"-Getöns die verwendete Kryptografie eingeschränkt werden. Vorsicht: "Crypto-policies" kann zu grauen Haaren oder zu Haarausfall führen!
https://docs.redhat.com/en/documentatio ... -hardening

Code: Alles auswählen

# man crypto-policies

https://manpages.ubuntu.com/manpages/ja ... ies.7.html

Wenn Arch Linux kein "crypto_policies"-Getöns unterstützt und kein FIPS 140-2/FIPS 140-3-Zertifizierung aufweist, ist es keine ordentliche Linux-Distribution.
https://en.wikipedia.org/wiki/FIPS_140-3

https://ubuntu.com/security/fips

[geppi]

Bringt leider alles nichts. Hab auch mal TLSv1.3 dazugenommen:

Screenshot_20260126_110615.png

Leider ohne Erfolg.

Bei meiner Suche nach einer Lösung bin ich auf folgendes Issue gestoßen:

Too many advertised sig algs cause TLS server hang-up
https://github.com/open-quantum-safe/oq ... 2063371760

Auch hier bricht der Server den Handshake auf Grund ihm unbekannter Signatur Algorithmen ab.
Allerdings wurden dort die PQCs der openssl Version 3.2 mittels des oqsproviders absichtlich hinzugefügt.

ArchLinux benutzt die derzeit neueste Version 3.6 von openssl.
Also mal schauen was sich da seit der Version 3.2 getan hat und siehe da:

Changes between 3.4 and 3.5.0
https://github.com/openssl/openssl/blob ... 8-apr-2025

• .....

• The TLS Signature algorithms defaults now include all three ML-DSA variants as first algorithms.

• .....

Das sind also genau die ersten drei unsere Kandidaten in den angebotenen Signatur Algorithmen 0x0904 (mldsa44), 0x0905 (mldsa65), und 0x0906 (mldsa87).

Um den Verursacher festzunageln hab ich mal kurz ein Downgrade von openssl auf die Version 3.4.1 gemacht und schon klappts auch mit dem Nachbarn:

Code: Alles auswählen

[RADIUS-Server] 2026/01/26 12:02:03,478  Devicetime: 2026/01/26 12:02:03,964
Received RADIUS Authentication Request request 135 from X:
-->client matches static IPv4 table entry X
-->known attributes of request:
.......
   EAP-Message:
   (147 bytes)
   -->EAP Header
   EAP Packet Code     : Response
   EAP Packet Id       : 2
   EAP Packet Len      : 147
   EAP Packet Type     : TLS
   --> EAP/TLS Packet
   TLS Flags           :
   --> SSL/TLS Record
   Record Content Type : Handshake
   Record Length       : 136
   Protocol Version    : TLSv1
   Handshake Msg Type  : Client Hello
   Message Length      : 132
   -->SSL/TLS Client Hello
   Protocol Version    : TLSv1.2
   Client Random       : e5 15 ac f7 9e 64 ca 93 .....d..
                         61 20 c8 ef aa 62 5d 51 a ...b]Q
                         f4 34 b9 5c 76 75 fa ef .4.\vu..
                         ee 3f 7a 44 85 60 8f 5d .?zD.`.]
   Cipher Suites       : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   Compression Methods : NULL
   Reneg. Info         :
   EC-Point Formats    : uncompressed
                         ansiX962_compressed_prime
                         ansiX962_compressed_char2
   Supported Groups    : ecdh_x25519
                         secp256r1
                         ecdh_x448
                         secp521r1
                         secp384r1
   Encrypt-Then-MAC    :
   Ext. Master Secret  :
   Sign. Algorithms    : ecdsa_secp256r1_sha256
                         ecdsa_secp384r1_sha384
                         ecdsa_secp521r1_sha384
                         ed25519
                         ed448
                         0x081a
                         0x081b
                         0x081c
                         rsa_pss_pss_sha256
                         rsa_pss_pss_sha384
                         rsa_pss_pss_sha512
                         rsa_pss_rsae_sha256
                         rsa_pss_rsae_sha384
                         rsa_pss_rsae_sha512
                         rsa_pkcs1_sha256
                         rsa_pkcs1_sha384
                         rsa_pkcs1_sha512
                         ecdsa_sha224
                         rsa_pkcs1_sha224
                         dsa_sha224
                         dsa_sha256
                         dsa_sha384
                         dsa_sha512
   WLAN-Pairwise-Cipher: TGI-CSE-CCMP128
   WLAN-Group-Cipher   : TGI-CSE-CCMP128
   WLAN-AKM-Suite      : TGI-AUTHSE-8021X-SHA256
   WLAN-Group-Mgmt-Cipher: TGI-CSE-BIPCMAC128
   WLAN-RF-Band        : 2.4-GHz
-->user name contains no realm, using empty realm
-->realm of user is ''
-->authenticating locally
-->found user 'skye.ofc.digitx.de' in database(s)
-->authenticating via EAP
-->queueing request for later response

Code: Alles auswählen

[TLS] 2026/01/26 12:02:03,510  Devicetime: 2026/01/26 12:02:03,965
Receiving Client Hello on connection 189429:
-> parsing TLS extensions
-> protocol version is TLSv1.2
-> selected x25519 as named group
-> enable extended master secret usage
-> created new session id
-> select cipher:
 -> check cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 -> PFS suite or no PFS preference, selection done
-> selected cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-> selected signature scheme is rsa_pkcs1_sha256
-> selected elliptic curve is x25519
-> selected elliptic curve point format is uncompressed
-> client supports secure renegotiation (by extension), enable it
-> all fine, ready to send Server Hello

Beim vorhanden sein der unbekannten PQCs verhält sich der Lancom also auch so, wie Richard Levitte es in dem Issue thread salop formuliert hat: "The server like, "yo'weeeird, I'm walking away"

Leider hab ich damit aber immer noch keine Lösung des Problems, da ein Downgrade der openssl, auf Grund der vielen Pakete die von ihr abhängen, keinen brauchbaren Betrieb ermöglicht. Ich müsste das ganze System auf einen Stand vom April 2025 bringen und einfrieren.

Auf meinem Lancom 1781VA läüft die zur Zeit neueste Release für das Gerät 10.80RU13.
Bin mal gespannt wie weit die Produktpflege bei Lancom noch geht.
Ich würde das Verhalten mal als Bug einordnen, da der Lancom die unbekannten Algorithmen ja ignorieren könnte und der notwendige Algorithmus angeboten wird.
Auf jeden Fall wird die LCOS Version 10.80 ab der openssl Version 3.5 für EAP-TLS unbrauchbar.

Könnte das vielleicht ein Mitleser mit etwas mehr Reputation als ich kleiner Consumer Feld, Wald und Wiesenkunde als Bug melden?

[rotwang]

Moin,

das Problem könnte schlicht die Menge der vom Client angebotenen Signaturverfahren sein:

Code: Alles auswählen

   Sign. Algorithms    : 0x0905
                         0x0906
                         0x0904
                         ecdsa_secp256r1_sha256
                         ecdsa_secp384r1_sha384
                         ecdsa_secp521r1_sha384
                         ed25519
                         ed448
                         0x081a
                         0x081b
                         0x081c
                         rsa_pss_pss_sha256
                         rsa_pss_pss_sha384
                         rsa_pss_pss_sha512
                         rsa_pss_rsae_sha256
                         rsa_pss_rsae_sha384
                         rsa_pss_rsae_sha512
                         rsa_pkcs1_sha256
                         rsa_pkcs1_sha384
                         rsa_pkcs1_sha512
                         ecdsa_sha224
                         rsa_pkcs1_sha224
                         dsa_sha224
                         dsa_sha256
                         dsa_sha384
                         dsa_sha512

Das sind 26 Stück, und für die Algorithmen, die das LCOS im Trace nicht namentlich auflösen kann, muß ich erstmal schauen, welcher RFC sie definiert (Update: gefunden, ist noch ein Draft).

Das Problem könnte aber schlicht sein, dass eine Datenstruktur im LCOS, die die Algorithmenliste von der Gegenseite speichert, im Moment maximal 16 Einträge aufnehmen kann. Mehr führen zu keinem Pufferüberlauf, aber sie werden einfach nicht gespeichert und können im nächsten Schritt nicht ausgewählt werden. Und so wie ich's überblicke, stehen die 'rsa_pkcs1_...'-Algorithmen, die bei dem anderen Client gewählt werden, ab Nummer 18 in der Liste...ich kümmere mich morgen drum, heute habe ich noch Urlaub.

Sowohl die mldsa-Algorithmen als auch die Brainpool-Kurven-Algorithmen sind so wie ich es verstehe aber nur in Zusammenhang mit TLS 1.3 oder höher verwendbar. Andererseits ist im Client Hello keine Version-Extension drin, um TLS 1.3 auszuhandeln, deshalb kommt TLS 1.2 als Protokollversion heraus. Die Algorithmen in der Liste hätte der Client sich also eigentlich sparen können?

Ein 1781VA (over ISDN) ist lt. Lifecycle im letzten Monat EoL gegangen. Die POTS-Version ist wohl noch länger verkauft worden und erst in einem Jahr EoL...ich will an dieser Stelle aber keine erneute Diskussion über das Thema vom Zaun brechen (bringt an diesem Ort eh nichts), und nach Erfahrungen in früheren Fällen gehe ich davon aus, dass man das mit dem EoL auch in diesem Fall eher grosszügig auslegen wird.

[geppi]

Vielen Dank!

Sowohl die mldsa-Algorithmen als auch die Brainpool-Kurven-Algorithmen sind so wie ich es verstehe aber nur in Zusammenhang mit TLS 1.3 oder höher verwendbar. Andererseits ist im Client Hello keine Version-Extension drin, um TLS 1.3 auszuhandeln, deshalb kommt TLS 1.2 als Protokollversion heraus. Die Algorithmen in der Liste hätte der Client sich also eigentlich sparen können?

Ja definitiv, aber leider scheint openssl immer den kompletten Satz der eigenen DEFAULT offers zu schicken, egal welche TLS Version benutzt wird.

Unter Linux wird WiFi fast überall mit dem wpa_supplicant bedient. Dieser bietet zwar die Möglichkeit, die angebotenen Ciphers zu beschränken, wovon ich auch gebrauch gemacht habe. Im Trace oben bietet er damit nur noch TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 an.

Ich habe bis jetzt aber leider noch keine Möglichkeit gefunden die Signatur Algorithmen zu limitieren.

Mein Versuch mit dem Downgrade der openssl auf Version 3.4 zeigt auch, dass der wpa_supplicant im Backend die openssl für die Crypto-Aufgaben verwendet. Ich bin immernoch auf der Suche, ob es in der openssl eine Möglichkeit gibt die Liste zu limitieren.

Das Problem könnte aber schlicht sein, dass eine Datenstruktur im LCOS, die die Algorithmenliste von der Gegenseite speichert, im Moment maximal 16 Einträge aufnehmen kann. Mehr führen zu keinem Pufferüberlauf, aber sie werden einfach nicht gespeichert und können im nächsten Schritt nicht ausgewählt werden. Und so wie ich's überblicke, stehen die 'rsa_pkcs1_...'-Algorithmen, die bei dem anderen Client gewählt werden, ab Nummer 18 in der Liste...

Auch dann würde eine Limitierung der angebotenen Algorithmen ja helfen.
Ich find' bis jetzt nur leider nix.

[Dr.Einstein]

Hut ab vor deiner Analyse geppi und danke fürs Teilen. Kannst du mal

Code: Alles auswählen

phase1="tls_disable_tlsv1_3=1"

probieren in deiner wpa Konfig? Angeblich soll dies die Liste reduzieren.

[GrandDixence]

Oder man stutzt OpenSSL über die Konfigurationsdatei openssl.cnf zurecht.

Code: Alles auswählen

# man openssl.cnf

https://wiki.archlinux.org/title/OpenSSL

Dies ist der Weg, welcher crypto_policies unter SUSE Linux Enterprise Desktop 15 SP7 (SLED15 SP7) bestreitet.

Code: Alles auswählen

# more /etc/ssl/openssl.cnf |grep -i crypto
# security critical operations, as they are cryptographically weak or vulnerable
system_default = crypto_policy
[ crypto_policy ]
.include = /etc/crypto-policies/back-ends/opensslcnf.config
crypto_device	= builtin		# OpenSSL engine to use for signing

Code: Alles auswählen

# more /etc/crypto-policies/back-ends/opensslcnf.config
CipherString = @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256
TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProtocol = DTLSv1.2
DTLS.MaxProtocol = DTLSv1.2
SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA3
84:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Groups = X25519:secp256r1:X448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192

Wie unschwer zu erkennen ist, hatte ich noch nicht die Zeit und die Nerven, mit Hilfe von crypto_policies diese Linux-Installation BSI TR-02102 konform zu machen.

Code: Alles auswählen

# rpm -q wpa_supplicant --requires |grep -i ssl
libcrypto.so.3(OPENSSL_3.0.0)(64bit)
libssl.so.3()(64bit)
libssl.so.3(OPENSSL_3.0.0)(64bit)

# openssl --version
OpenSSL 3.2.3 3 Sep 2024 (Library: OpenSSL 3.2.3 3 Sep 2024)

# rpm -q crypto-policies
crypto-policies-20230920.570ea89-150600.3.12.1.noarch

Alle von OpenSSL unterstützte Ciphers listet der Befehl:

Code: Alles auswählen

# openssl ciphers -v

auf. Im "super-scharfen" FIPS:OSPP-Modus:

Code: Alles auswählen

# zypper install crypto-policies-scripts
# zypper install gnutls
# zypper install patterns-base-fips
# fips-mode-setup --enable
# reboot

# cat /proc/sys/crypto/fips_enabled
1

# dmesg |grep -i fips
# dmesg |grep -i alg:
# cat /proc/cmdline
... fips=1 ...

# gnutls-cli --fips140-mode
library is in FIPS140-3 mode

# update-crypto-policies --set FIPS:OSPP
# reboot

# update-crypto-policies --show
FIPS:OSPP

# update-crypto-policies --is-applied
The configured policy is applied

# update-crypto-policies --check
The configured policy matches the generated policy

# fips-mode-setup --check
FIPS mode is enabled.
Initramfs fips module is enabled.
The current crypto policy (FIPS:OSPP) is based on the FIPS policy.

ergibt das:

Code: Alles auswählen

# openssl ciphers -v
TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any      Au=any   Enc=AESGCM(256)            Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256)            Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH     Au=RSA   Enc=AESGCM(256)            Mac=AEAD
DHE-RSA-AES256-GCM-SHA384      TLSv1.2 Kx=DH       Au=RSA   Enc=AESGCM(256)            Mac=AEAD
DHE-RSA-AES256-SHA256          TLSv1.2 Kx=DH       Au=RSA   Enc=AES(256)               Mac=SHA256
PSK-AES256-GCM-SHA384          TLSv1.2 Kx=PSK      Au=PSK   Enc=AESGCM(256)            Mac=AEAD
DHE-PSK-AES256-GCM-SHA384      TLSv1.2 Kx=DHEPSK   Au=PSK   Enc=AESGCM(256)            Mac=AEAD

Viel Glück!

[geppi]

Wie heisst es so schön: "Problem erkannt, Problem gebannt".

Erst mal vielen Dank an alle!

Die Option

Code: Alles auswählen

phase1="tls_disable_tlsv1_3=1"

hatte ich schon ausprobiert, bringt leider auch nix.

Aber, obwohl Arch Linux offensichtlich keine ordentliche Linux-Distribution ist, weil es kein "crypto_policies-Getöns" unterstützt bietet das vorhandene openssl Paket natürlich alle Möglichkeiten der Konfiguration die OpenSSL eben so hat.

Dem folgenden Auszug entnehme ich, dass die crypto_policies auch nix anderes sind als eine glorifizierte Include-Datei für die openssl.cnf.

Dies ist der Weg, welcher crypto_policies unter SUSE Linux Enterprise Desktop 15 SP7 (SLED15 SP7) bestreitet.

Code: Alles auswählen

# more /etc/ssl/openssl.cnf |grep -i crypto
# security critical operations, as they are cryptographically weak or vulnerable
system_default = crypto_policy
[ crypto_policy ]
.include = /etc/crypto-policies/back-ends/opensslcnf.config
crypto_device	= builtin		# OpenSSL engine to use for signing

Also, ran ans Werk und RTFM.
OK, eine verwirrendere kreuz und quer Referenzierung von manpages ist mir auch schon lange nicht mehr unter gekommen.
Die notwendige Konfiguration stand hier unter anderem auch schon drin:

Code: Alles auswählen

# more /etc/crypto-policies/back-ends/opensslcnf.config
CipherString = @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
Ciphersuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256
TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProtocol = DTLSv1.2
DTLS.MaxProtocol = DTLSv1.2
SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA3
84:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Groups = X25519:secp256r1:X448:secp521r1:secp384r1:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192

Aber ich versteh' halt gerne was ich mache.
Was schlussendlich notwendig ist um die angebotenen Signatur Algorithmen einzuschränken sind folgende Einträge in der openssl.cnf.

Code: Alles auswählen

# Use this in order to automatically load providers.
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect
ssl_conf = ssl_configuration

# List of providers to load
[provider_sect]
default = default_sect
# The fips section name should match the section name inside the
# included fipsmodule.cnf.
# fips = fips_sect

# If no providers are activated explicitly, the default one is activated implicitly.
# See man 7 OSSL_PROVIDER-default for more details.
#
# If you add a section explicitly activating any other provider(s), you most
# probably need to explicitly activate the default provider, otherwise it
# becomes unavailable in openssl.  As a consequence applications depending on
# OpenSSL may not work correctly which could lead to significant system
# problems including inability to remotely access the system.
[default_sect]
# activate = 1

# SSL/TLS configuration
[ssl_configuration]
system_default = tls_system_default


# Defaults for the SSL/TLS configuration
[tls_system_default]
SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:ecdsa_sha224:rsa_pkcs1_sha224:dsa_sha224:dsa_sha256:dsa_sha384:dsa_sha512

Der entscheidende Eintrag ist ganz am Ende "SignatureAlgorithms = ....", der Rest ist dem Aufbau der openssl.cnf in Sektionen geschuldet und der Tatsache, dass diese bestimmte Namen haben müssen um bestimmte Dinge zu konfigurieren.

Mit dem oben angegebenen Beispiel konfiguriert man die angebotenen Signatur Algorithmen auf den Stand der openssl Version 3.4 zurück, allerdings ohne die Algorithmen 0x081a, 0x081b und 0x081c, die das LCOS 10.80RU13 eh nicht kennt.

Fazit: LCOS 10.80RU13 hat ein Problem mit openssl Versionen ab 3.5 in der Standardkonfiguration, aber es gibt einen Workaround.

[rotwang]

Ich habe das Limit für die 10.80...10.92 verdreifacht bzw. für die 10.94 komplett entfernt. Ob und wann neue RUs damit kommen, habe ich aber keinen Einfluß.

[geppi]

Super, danke!

Dann wird's ja auch wahrscheinlich irgendwann in der openssl Standardkonfiguration gehen. Bis dahin tut's der Workaround.