EAP-TLS Signature Check Failure

[nabble at felix.world]

Hi Together, 

we finally got the issue and for the anyone else, how will face the issue, the fix is quite simple. Update your TPM Firmware!

In fact, during the authentication the client is sending a signature which only includes nulls. The packet itself is intact, sizes of the packets are valid and the signature algorithm is also well. The only thing that's not in the tls authentication is a signature. : 

````
(4) eap_tls: <<< recv TLS 1.2  (type: 0016) [length 0108] handshake_type: 0f, alert_level: 00, alert_description: 00
0f000104    TLS handshake certificate_verify len 0x000104 = 260
0804        signature algorithm: rsa_pss_rsae_sha256
0100        signature size: 0x0100 = 256
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 00000000000000000000
00000000000000000000 000000000000
````
That's also the reason why some of our clients are able to authenticate and some not, with the key, stored in TPM. 

Intel ships end customer TPM updater, STM as we know not. We also don't have clients with Infineon chips but they should also ship updates to the end customer. 

FYI: This was a team operation and thanks to all that helped here. 

Regards, 
Lineconnnect

<quote author='Users mailing list'>
2 months later, a quick update on this topic (apologies, I may have 
broken the threading as I don't have a copy of the original e-mails any 
more!), just so there's an online reference here for anyone encountering 
the same error.

Turns out I was wrong about it being Windows and OpenSSL getting muddled 
over TLS 1.2 vs. 1.3...

To recap: Windows 10 clients, corporate WiFi network using EAP-TLS to 
RADIUS with machine certificate (SCEP) authentication only.

Error in Freeradius logs:

(6) eap_tls: ERROR: TLS Alert write:fatal:decrypt error
tls: TLS_accept: Error in error
(6) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read)
(6) eap_tls: ERROR: error:0407E086:rsa 
routines:RSA_verify_PKCS1_PSS_mgf1:last octet invalid
(6) eap_tls: ERROR: error:1417B07B:SSL 
routines:tls_process_cert_verify:bad signature
(6) eap_tls: ERROR: System call (I/O) error (-1)
(6) eap_tls: ERROR: TLS receive handshake failed during operation
(6) eap_tls: ERROR: [eaptls process] = fail

After encountering the error on a few machines again, even with 
"tls_max_version" set, I delved into the guts of Windows again, and 
found the error (which isn't helpful or descriptive) was actually caused 
because:

* Some machine certificates had were stored/managed by the "Microsoft 
Platform Crypto Provider" (TPM-backed)
* Built-in security measures control access to keys in that CSP, and it 
cannot be used non-interactively
* Windows WiFi profile was set to auto-join (non-interactive)
* Windows couldn't get the key, so $deity knows what signature it was 
sending
* OpenSSL rightly got confused

The solution:

Ensure machine certificate keys are stored in the "Microsoft Software 
Key Storage Provider" (or another CSP/KSP that permits non-interactive 
use).

All is well again, and I'm close to shutting down NPS :-)

-- 
Peter Bance
Information Security Adviser

Alan DeKok wrote:
> A final update on this, in case anyone here's interested (or to "wrap 
> up" for anyone stumbling across this thread online) - I fixed it, and 
> Windows clients are now happily joining WiFi. It's a beautiful thing to 
> behold :-)
> 
> In the end, I had to force OpenSSL on FreeRADIUS to stop offering 
> TLS1.3 ciphers using the mods/eap config:
> 
> tls_max_version = "1.2"

   Good to hear.

> It seems there may be a bug in OpenSSL 1.1.1 such that even though the 
> negotiation resulted in a TLS 1.2 session, the weird back-port of TLS 
> 1.3 ciphers into TLS 1.2 confused things (a lot), and it tried checking 
> for TLS 1.3 style signatures inappropriately.

   Weird, but OK.  It's OpenSSL :(

   Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
</quote>
Quoted from: 
http://freeradius.1045715.n5.nabble.com/RE-EAP-TLS-Signature-Check-Failure-tp5758407.html


_____________________________________
Sent from http://freeradius.1045715.n5.nabble.com