PSK Support

[Maxim Dounin]

Hello!

On Wed, Jun 07, 2017 at 05:02:52AM +0000, Karstens, Nate wrote:

> Maxim,
> 
> The biggest downside that I can see to the dummy certificate 
> approach is documentation. Using a dummy certificate wasn't 
> immediately obvious to me, though perhaps my familiarity with 
> OpenSSL's "nocert" option may have affected that. Which do you 
> think would be easier for the user to find in the documentation: 
> 1) a description of the dummy certificate approach under the 
> "ssl_certificate" directive, 2) a separate directive 
> ("ssl_nocert"), or 3) an explicit option to the 
> "ssl_certificate" directive (e.g., " Syntax: ssl_certificate 
> file | off;")?

In most cases, normal users won't need PSK at all, or will use it 
combined with certificates anyway.  Describing in the 
documentation that "if you need to use PSK only, you still have to 
configure a certificate" doesn't looks like a big problem to me.

Note well that there is a side problem with "listen ... ssl" used 
in server block but no ssl_certificate configured for the server.  
As of now, it is not reported during configuration parsing and may 
result in non-obvious behaviour in some cases, see ticket #178 
(https://trac.nginx.org/nginx/ticket/178).  This is a separate 
problem though, and it can't be fixed with the changes suggested.  
On the other hand, properly fixing it will greatly improve user 
experience in many cases, including PSK.

> I'm OK with changing it to read from a password file (formatted 
> in a manner similar to stunnel) that is searched as needed (an 
> "ssl_psk_file" directive). Would it be OK to support multiple 
> files and stipulate that files are searched in the order that 
> they are included in nginx.conf?

I don't think that supporting multiple files is a good idea, a 
single one should be enough.

Possible alternative names:

- "ssl_psk_secrets", similar to the one used by stunnel;
- "ssl_pre_shared_keys".

Not sure if these are better though.

> Can we support both ASCII and binary PSKs? RFC 4279 section 5.4 
> seems to require both types, and I need binary keys for my 
> application :). Maybe a parameter to the "ssl_psk_file" 
> directive could indicate how the PSKs are stored in the file?

We can consider providing an alternative form to allow arbitrary 
keys, e.g., by using hex-encoded keys.  This can be done using 
some explicit prefix, something like this:

identity:key
identity:0x6b6579
identity:{HEX}6b6579

(The last variant is in line with "{scheme}data" syntax as used in 
auth_basic_user_file.  Not sure if we need it here, just "0x" 
might be easier.)

-- 
Maxim Dounin
http://nginx.org/