So, I gather that "recv TLS 1.3" does not necessarily mean that the client *requires* TLS 1.3. Then,"send TLS 1.0" might mean that we offered TLS 1.0 but a cipher the client refused. There's no way to tell which is the culprit (TLS or cipher suite)? In freeradius eap I have: cipher_list = "DEFAULT" cipher_server_preference = no So I guess I'm not being very picky, am I? Maybe I can be more permissive by changing "DEFAULT" to an explicit list? Vieri
On Jun 29, 2020, at 9:24 AM, Vieri via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
So, I gather that "recv TLS 1.3" does not necessarily mean that the client *requires* TLS 1.3.
It's a request.
Then,"send TLS 1.0" might mean that we offered TLS 1.0 but a cipher the client refused. There's no way to tell which is the culprit (TLS or cipher suite)?
You can use wireshark to decode the TLS packets. It should show you the various ciphers.
In freeradius eap I have:
cipher_list = "DEFAULT" cipher_server_preference = no
So I guess I'm not being very picky, am I? Maybe I can be more permissive by changing "DEFAULT" to an explicit list?
The only solution is to *add* the ciphers used by the other end. But the other end shouldn't be using TLS 1.3. It's not standardized yet for use with EAP. Alan DeKok.
participants (2)
-
Alan DeKok -
Vieri