
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>

</head>

<body dir="ltr">

<font style="font-size: 11pt;" face="Calibri, sans-serif" color="#000000"><b>Von:</b> radiator <radiator-bounces@lists.open.com.au> im Auftrag von Heikki Vatiainen <hvn@open.com.au></font><br>

<div id="divRplyFwdMsg" dir="ltr"><font style="font-size: 11pt;" face="Calibri, sans-serif" color="#000000"><b>Gesendet:</b> Mittwoch, 2. Juni 2021 17:01<br>

<b>An:</b> radiator@lists.open.com.au <radiator@lists.open.com.au><br>

<b>Betreff:</b> Re: [RADIATOR] AuthBy DUO issue</font>

<div> </div>

</div>

<div class="BodyFragment"><font size="2"><span style="font-size:11pt">

<div class="PlainText">On 1.6.2021 19.23, Alexander.Hartmaier@t-systems.com wrote:<br>

<br>

> today at noon I had the change to reenable Cisco Duo and set TLS to v1.2.<br>

> So far it looks good, I saw other authentication requests getting <br>

> processed while AuthBy DUO waited for a user response.<br>

<br>

Thanks for the update. Please keep us posted if the situation changes.</div>

<div class="PlainText"><br>

</div>

<div class="PlainText">So far the TLSv1.2 workaround works.<br>

</div>

<div class="PlainText"><br>

> I haven't grapsed so far how TLSv1.3 could cause this bug?<br>

> If I understood it correctly, the underlying socket reports available <br>

> data via select although none has been received so far [1].<br>

> Is that correct?<br>

<br>

That's my hunch too. That is, I did not verify it throughly but it <br>

looked familiar.<br>

<br>

> How does the TLS version influence that?<br>

<br>

TLSv1.3 is much different from SSL3.0 - TLSv1.2. One major difference is <br>

the way session resumption works with TLSv1.3. With the other versions, <br>

information needed for resumption was communicated between the peers <br>

during the TLS handshake. With TLSv1.3 the handshake complets first and <br>

then the optional resumption information (Pre-Shared Keys) are sent by <br>

the server. The main thing is that it's now normal to receive non-data <br>

records after handshake has finished.<br>

<br>

With TLSv1.3, when the the socket indicates it's readable, there's no <br>

userdata and the read blocks. It does update the session's internal <br>

state and ability to resume, though.<br>

<br>

I think this is a good explanation what I think might be happening with <br>

[1] below.<br>

<br>

<a href="https://wiki.openssl.org/index.php/TLS1.3#Non-application_data_records">https://wiki.openssl.org/index.php/TLS1.3#Non-application_data_records</a></div>

<div class="PlainText"><br>

</div>

<div class="PlainText">That makes sense!</div>

<div class="PlainText">But when OpenSSL receives and reads that data, shouldn't the socket stop reporting available data?<br>

</div>

<div class="PlainText"><br>

</div>

<div class="PlainText">What is your plan to fix this issue?</div>

<div class="PlainText">Will you provide a patch for HTTP::Async or migrate AuthDUO.pm to for example AuthREST.pm?<br>

</div>

<div class="PlainText"><br>

> [1] <br>

> <a href="https://metacpan.org/release/HTTP-Async/source/lib/HTTP/Async.pm#L551">

https://metacpan.org/release/HTTP-Async/source/lib/HTTP/Async.pm#L551</a> <br>

<br>

Thanks,<br>

Heikki</div>

<div class="PlainText"><br>

</div>

<div class="PlainText">Thanks, Alex<br>

</div>

</span></font></div>

</body>

</html>