On 1.6.2021 19.23, [email protected] wrote:
today at noon I had the change to reenable Cisco Duo and set TLS to v1.2.
So far it looks good, I saw other authentication requests getting
processed while AuthBy DUO waited for a user response.
Thanks for the update. Please keep us posted if the situation changes.
I haven't grapsed so far how TLSv1.3 could cause this bug?
If I understood it correctly, the underlying socket reports available
data via select although none has been received so far [1].
Is that correct?
That's my hunch too. That is, I did not verify it throughly but it
looked familiar.
How does the TLS version influence that?
TLSv1.3 is much different from SSL3.0 - TLSv1.2. One major difference is
the way session resumption works with TLSv1.3. With the other versions,
information needed for resumption was communicated between the peers
during the TLS handshake. With TLSv1.3 the handshake complets first and
then the optional resumption information (Pre-Shared Keys) are sent by
the server. The main thing is that it's now normal to receive non-data
records after handshake has finished.
With TLSv1.3, when the the socket indicates it's readable, there's no
userdata and the read blocks. It does update the session's internal
state and ability to resume, though.
I think this is a good explanation what I think might be happening with
[1] below.
https://wiki.openssl.org/index.php/TLS1.3#Non-application_data_records
[1]
https://metacpan.org/release/HTTP-Async/source/lib/HTTP/Async.pm#L551
Thanks,
Heikki
--
Heikki Vatiainen <[email protected]>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
_______________________________________________
radiator mailing list
[email protected]
https://lists.open.com.au/mailman/listinfo/radiator
