Some problems with TLS 1.3 and PSK

[Alan DeKok]

On Jan 14, 2019, at 2:16 PM, Alejandro Pérez Méndez <alex at 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.