Some problems with TLS 1.3 and PSK

[Alejandro Pérez Méndez]

>> 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