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