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