Some problems with TLS 1.3 and PSK

Alex Perez-Mendez Alex.Perez-Mendez at jisc.ac.uk
Mon Jan 14 16:38:52 CET 2019


> On Jan 14, 2019, at 7:48 AM, Alex Perez-Mendez <Alex.Perez-Mendez at jisc.ac.uk> wrote:
>> as you know, Moonshot and the Trust Router use dynamically established
>> TLS PSK for allowing communication between RADIUS servers.
>> This has been working nicely so far, but I've started testing with
>> Debian Buster, which ships OpenSSL 1.1 which defaults to TLS 1.3 and
>> I've found some issues with both, 3.0.17 and 3.0.18.
>    The 3.0.17 issue was due to a typo in a macro.  See commit fd803c9d35592

Yeah, I saw that before sending my email, but that was more related to 
FR not being able to print TLS version, wasn't it? The error I was 
referring to was the "Error in fragmentation logic"

>
>    The 3.0.18 issue is due to trying to fix other issues.  :(  And, OpenSSL seems to change its behaviour rather a lot.  Things which work in one version don't work in another.

I know. My main worries were indeed that was something that OSSL decided 
to change something, and that would take more than just a small fix to 
make it work.
In particular, it seems (from the behaviour) that when using OSSL 1.0, 
even if you decided to have certificates, etc., if a PSK cipher was 
negotiated, that part was not taken into account.
However, if FR initialises cert-specific parameters, even when a PSK 
cipher is negotiated, it does not work.


>
>> In this case, the issue seems to have been caused by this commit
>> https://github.com/FreeRADIUS/freeradius-server/commit/f2d93cffbd1a78ae2dbf136d8a0c41173c172f1d,
>> as reverting it reverts to the previous issue with 3.0.17.
>    That commit should still be done, as it fixes other issues...
>
>    I've pushed a fix to the v3.0.x branch which turns that check into a soft fail.  I think that should fix it, while also initializing the ssl_session variable.

That makes 3.0.18 behaves as 3.0.17, that is, it does not fail with any 
Session-related issue, but still fails negotiating TLS.

Ready to process requests
  ... new connection request on TCP socket
Listening on auth from client (172.17.0.3, 35110) -> (*, 2083, 
virtual-server=abfab-idp)
Waking up in 0.6 seconds.
(0) Initiating new TLS session
(0) Setting verify mode to require certificate from client
(0) (other): before SSL initialization
(0) TLS_accept: before SSL initialization
(0) TLS_accept: before SSL initialization
(0) <<< recv TLS 1.3  [length 0176]
rlm_sql (psksql): Reserved connection (0)
(0) Executing select query: select 
'03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3' 
from (select 'x' as dummy)
rlm_sql (psksql): Released connection (0)
(0) EXPAND %{psksql:select 
'03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3' 
from (select 'x' as dummy)}
(0)    --> 
03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3
(0) TLS_accept: SSLv3/TLS read client hello
(0) >>> send TLS 1.3  [length 0058]
(0) TLS_accept: SSLv3/TLS write server hello
(0) >>> send TLS 1.3  [length 0001]
(0) TLS_accept: SSLv3/TLS write change cipher spec
(0) TLS_accept: TLSv1.3 early data
(0) TLS_accept: Need to read more data: TLSv1.3 early data
(0) TLS - In Handshake Phase
(0) TLS - got 99 bytes of data
Waking up in 0.6 seconds.
(0) <<< recv TLS 1.3  [length 0002]
(0) ERROR: TLS Alert read:fatal:internal error
(0) TLS_accept: Need to read more data: error
(0) ERROR: Failed in __FUNCTION__ (SSL_read): error:14094438:SSL 
routines:ssl3_read_bytes:tlsv1 alert internal error
(0) TLS - In Handshake Phase
(0) TLS - Application data.
(0) SSL_read Error
(0) ERROR: Error in fragmentation logic



Note that
openssl s_server -psk 
03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3 
-psk_identity key-2378d1 -cert /usr/local/etc/raddb/certs/server.pem 
-key /usr/local/etc/raddb/certs/server.key -msg -port 2083

Does work perfectly fine using the very same client command.




Also note that hardcoding "psk_hexphase" and "psk_identity", and 
disabling any certificate configuration on the server works as well 
(even keeping the psk_query parameter).

Waking up in 0.1 seconds.
(0) Initiating new TLS session
(0) (other): before SSL initialization
(0) TLS_accept: before SSL initialization
(0) TLS_accept: before SSL initialization
(0) <<< recv TLS 1.3  [length 0176]
rlm_sql (psksql): Reserved connection (0)
(0) Executing select query: select 
'03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3' 
from (select 'x' as dummy)
rlm_sql (psksql): Released connection (0)
(0) EXPAND %{psksql:select 
'03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3' 
from (select 'x' as dummy)}
(0)    --> 
03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3
(0) TLS_accept: SSLv3/TLS read client hello
(0) >>> send TLS 1.3  [length 0058]
(0) TLS_accept: SSLv3/TLS write server hello
(0) >>> send TLS 1.3  [length 0001]
(0) TLS_accept: SSLv3/TLS write change cipher spec
(0) TLS_accept: TLSv1.3 early data
(0) TLS_accept: Need to read more data: TLSv1.3 early data
(0) TLS - In Handshake Phase
(0) TLS - got 99 bytes of data
Waking up in 0.1 seconds.
(0) TLS_accept: TLSv1.3 early data
(0) <<< recv TLS 1.3  [length 0197]
rlm_sql (psksql): Reserved connection (1)
(0) Executing select query: select 
'03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3' 
from (select 'x' as dummy)
rlm_sql (psksql): Released connection (1)
(0) EXPAND %{psksql:select 
'03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3' 
from (select 'x' as dummy)}
(0)    --> 
03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3
(0) TLS_accept: SSLv3/TLS read client hello
(0) >>> send TLS 1.3  [length 00a1]
(0) TLS_accept: SSLv3/TLS write server hello
(0) >>> send TLS 1.3  [length 0001]
(0) >>> send TLS 1.3  [length 0006]
(0) TLS_accept: TLSv1.3 write encrypted extensions
(0) >>> send TLS 1.3  [length 0001]
(0) >>> send TLS 1.3  [length 0024]

So it seems that somehow it has to do with how certificate stuff is 
initialised.

Best regards,
Alex

>    Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

-- 
Alejandro Perez-Mendez
Technical Specialist (AAA), Trust & Identity
M (+34) 619 333 219
Skype alejandro_perez_mendez
jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.  



More information about the Freeradius-Devel mailing list