Some problems with TLS 1.3 and PSK
Hi guys, 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. All the problems are not shown if tls_max_version = 1.2 is used. In 3.0.17, problems only arise when psk_query is used with the certificate TLS configuration parameters. When using psk_hexphrase and psk_identity without any certificate parameter, everything works as well. This is what happens with psk_query + certificates activated: On the client: openssl s_client -connect 172.17.0.2:2083 -psk 03592CFAD91DB9E6DBDC022A80E14D15B62493C7D6D114272FD70374EA920E75DEB5DFC760487D96F8E1D4310FC617167DD539CB4245BEFE083BE71CA28F937A13EE3ECA0EBC4FC6687A948CE0F32FBF99AAF2B9024EAEF5688B1CA054F3DDA54D65277223ED25FB3C2D7F39FDE1FE1D2EF1D8B6F04F97121095A077A33784CD2754E0E6A8511F5DC334A0394E41B7300ED7ACCC62F8903B9092A0CD40FA12F8DC825852BD080292519450F37C80D96033704E86E36874635D800F0AD4230E9C9343060E25343BF9D33A12B979EF6318A6F32FCE9791423C82DE8DCF17634247592D86F4F5029CFF258D6DDC8ADDFB6223E02C8B7843C991686966775B9044D3 -psk_identity key-2378d9 -cipher aPSK On the server: Listening on auth from client (172.17.0.3, 34362) -> (*, 2083, virtual-server=abfab-idp) Waking up in 0.4 seconds. (0) Initiating new EAP-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 UNKNOWN TLS VERSION ?0304? [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 UNKNOWN TLS VERSION ?0304? [length 0058] (0) TLS_accept: SSLv3/TLS write server hello (0) >>> send UNKNOWN TLS VERSION ?0304? [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) In SSL Handshake Phase (0) In SSL Accept mode Waking up in 0.4 seconds. (0) <<< recv UNKNOWN TLS VERSION ?0304? [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) In SSL Handshake Phase (0) In SSL Accept mode (0) SSL Application Data (0) SSL_read Error (0) ERROR: Error in fragmentation logic (0) Application data status 4 Waking up in 0.4 seconds. Closing TLS socket from client port 34362 In 3.0.18, things are different. It complains about the session: ... new connection request on TCP socket Listening on auth from client (172.17.0.3, 34384) -> (*, 2083, virtual-server=abfab-idp) Waking up in 0.9 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 - Failed getting session (0) FAILED in TLS handshake receive Closing TLS socket from client port 34384 Client has closed connection ... shutting down socket auth from client (172.17.0.3, 34384) -> (*, 2083, virtual-server=abfab-idp) Waking up in 2.9 seconds. ... cleaning up socket auth from client (172.17.0.3, 34384) -> (*, 2083, virtual-server=abfab-idp) Ready to process requests In this case, the issue seems to have been caused by this commit https://github.com/FreeRADIUS/freeradius-server/commit/f2d93cffbd1a78ae2dbf1..., as reverting it reverts to the previous issue with 3.0.17. Any ideas with the issue with 3.0.17? Thanks, -- 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.
On Jan 14, 2019, at 7:48 AM, Alex Perez-Mendez <Alex.Perez-Mendez@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 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.
In this case, the issue seems to have been caused by this commit https://github.com/FreeRADIUS/freeradius-server/commit/f2d93cffbd1a78ae2dbf1..., 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. Alan DeKok.
On Jan 14, 2019, at 7:48 AM, Alex Perez-Mendez <Alex.Perez-Mendez@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/f2d93cffbd1a78ae2dbf1..., 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.
On Jan 14, 2019, at 10:38 AM, Alex Perez-Mendez <Alex.Perez-Mendez@jisc.ac.uk> wrote:
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"
OK.
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.
Hmm... having out work is the goal. :(
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. .. 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
That's an error produced by OpenSSL. We're trying to read from the BIO (memory buffer), and OpenSSL is saying "nope, that failed, and you shouldn't retry".
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.
So it's one of 1000 OpenSSL calls, or one of 1000 parameters pass to OpenSSL. The OpenSSL API is rather too magical for my liking.
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).
That should help narrow it down a bit more. It looks like the various code paths aren't *quite* the same. I've pushed some changes which complain if both psk_identity && psk_query are set. They shouldn't both be set. I've also pushed changes which complain if any PSK && CA config are used at the same time. Again, both shouldn't be set.
So it seems that somehow it has to do with how certificate stuff is initialised.
Which shouldn't be there if you're using PSK... From the EAP module config: # # If OpenSSL supports TLS-PSK, then we can use # a PSK identity and (hex) password. When the # following two configuration items are specified, # then certificate-based configuration items are # not allowed. e.g.: # # private_key_password # private_key_file # certificate_file # ca_file # ca_path The code enforced that for psk_identity, but allowed them for psk_query. And from your original message:
In 3.0.17, problems only arise when psk_query is used with the certificate TLS configuration parameters.
The solution, then, is to *not* use psk_query && certs at the same time. I don't think they were ever intended to be used at the same time, due to the restrictions on psk_identity. If the goal is to allow psk_query && certs at the same time, then I'd like to know why / how this works. It may then also be useful to allow psk_identity && certs at the same time, too. See the latest code. It should forbid the offending configuration, and therefore work by default. If you need PSK && certs, then there's one check which can be deleted or commented out. And then PSK && certs should be allow for *both* psk_query && psk_identity. Alan DeKok.
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 That's an error produced by OpenSSL. We're trying to read from the BIO (memory buffer), and OpenSSL is saying "nope, that failed, and you shouldn't retry".
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. So it's one of 1000 OpenSSL calls, or one of 1000 parameters pass to OpenSSL.
The OpenSSL API is rather too magical for my liking.
I know what you mean...
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). That should help narrow it down a bit more. It looks like the various code paths aren't *quite* the same.
I've pushed some changes which complain if both psk_identity && psk_query are set. They shouldn't both be set. I've also pushed changes which complain if any PSK && CA config are used at the same time. Again, both shouldn't be set.
Well.... (see below)
So it seems that somehow it has to do with how certificate stuff is initialised. Which shouldn't be there if you're using PSK...
From the EAP module config:
# # If OpenSSL supports TLS-PSK, then we can use # a PSK identity and (hex) password. When the # following two configuration items are specified, # then certificate-based configuration items are # not allowed. e.g.: # # private_key_password # private_key_file # certificate_file # ca_file # ca_path
The code enforced that for psk_identity, but allowed them for psk_query.
And from your original message:
In 3.0.17, problems only arise when psk_query is used with the certificate TLS configuration parameters. The solution, then, is to *not* use psk_query && certs at the same time. I don't think they were ever intended to be used at the same time, due to the restrictions on psk_identity.
But when psk_query you don't need to specify psk_identity. It is just used in the query as a parameter. psk_query = "%{psksql:select hex(key) from psk_keys where keyid = '%{TLS-PSK-Identity}'}"
If the goal is to allow psk_query && certs at the same time, then I'd like to know why / how this works. It may then also be useful to allow psk_identity && certs at the same time, too.
See the latest code. It should forbid the offending configuration, and therefore work by default. If you need PSK && certs, then there's one check which can be deleted or commented out. And then PSK && certs should be allow for *both* psk_query && psk_identity.
Having a TLS server supporting both, PSK and certs, at the same time is very convenient. In our case, Trust Router-based connections (that is, inter-realm ones), are always PSK based. But we offer a RADSEC-based proxy to our services, and that connection is based on certificates, not in Moonshot. So, with the same "listen" directive we handle both. (see the abfab-tls site as an example where both are configured at the same time). I guess that we could split them using different ports for each, but then we'd need to use a non-standard port for one of them. Best regards, Alex
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Jan 14, 2019, at 2:16 PM, Alejandro Pérez Méndez <alex@um.es> wrote:
But when psk_query you don't need to specify psk_identity. It is just used in the query as a parameter.
psk_query = "%{psksql:select hex(key) from psk_keys where keyid = '%{TLS-PSK-Identity}'}"
The point is that psk_query extends the functionality of psk_identity. And if psk_identity precluded using certs, the same could be said for psk_query.
If the goal is to allow psk_query && certs at the same time, then I'd like to know why / how this works. It may then also be useful to allow psk_identity && certs at the same time, too.
See the latest code. It should forbid the offending configuration, and therefore work by default. If you need PSK && certs, then there's one check which can be deleted or commented out. And then PSK && certs should be allow for *both* psk_query && psk_identity.
Having a TLS server supporting both, PSK and certs, at the same time is very convenient. In our case, Trust Router-based connections (that is, inter-realm ones), are always PSK based. But we offer a RADSEC-based proxy to our services, and that connection is based on certificates, not in Moonshot.
Makes sense, I guess. I just wasn't sure about the interaction between PSK && certs. OpenSSL is magical that way.
So, with the same "listen" directive we handle both. (see the abfab-tls site as an example where both are configured at the same time).
OK. I'll remove that restriction, then,
I guess that we could split them using different ports for each, but then we'd need to use a non-standard port for one of them.
No, I'll just fix the code. v3.0.x should then be able to use psk_query just fine... Alan DeKok.
I guess that we could split them using different ports for each, but then we'd need to use a non-standard port for one of them. No, I'll just fix the code.
v3.0.x should then be able to use psk_query just fine...
Thanks Alan, the latest changes made the server die Thread 1 "radiusd" received signal SIGSEGV, Segmentation fault. 0x00005555555afb5a in tls_init_ctx (conf=0x55555593ace0, client=0) at src/main/tls.c:2886 2886 if (conf->psk_identity || *conf->psk_identity) { Looks like a typo. I guess that || should've been a &&, right? There are a couple more among the new checks. Best regards, Alex -- 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.
participants (3)
-
Alan DeKok -
Alejandro Pérez Méndez -
Alex Perez-Mendez