Some problems with TLS 1.3 and PSK

[Alan DeKok]

On Jan 14, 2019, at 10:38 AM, Alex Perez-Mendez <Alex.Perez-Mendez at 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.