PSK Support

[Maxim Dounin]

Hello!

On Mon, Jun 05, 2017 at 02:08:15PM +0000, Karstens, Nate wrote:

> Maxim,
> 
> Thanks for the reply. I understand your concerns about PSK. We 
> discussed it quite a bit, but ultimately decided that a PKI was 
> not practical for our environment. We have to rely on the end 
> user to configure security and any solution using PKI would be 
> so difficult to work with that they just wouldn't bother with 
> security at all.

Ok, understood.  I think that PSK can be a reasonable alternative 
to using plain http in many cases.

> I considered some alternatives on the "ssl_nocert" option. My 
> preference would have been to analyze the supported cipher 
> suites (from "ssl_ciphers") and determine if any include a PSK, 
> but it does not look like OpenSSL exposes APIs to accomplish 
> this.

By default, nginx uses "HIGH:!aNULL:!MD5" as ciphers list, and 
this includes various PSK ciphers as well, so this approach 
doesn't look working even if there were appropriate APIs.

> Using a dummy certificate seemed more complicated than the 
> other two suggestions you had (using "ssl_certificate" with a 
> value of "off" or disabling the tests if there are PSK secrets), 
> so I'd prefer one of those two. What is your preference?

Using a dummy certificate has an obvious benefit of not requiring 
any changes to the code, and might actually be a good starting 
option.

Disabling the tests with PSK secrets might not work as expected 
when they are defined at the http{} level.  Using "ssl_certificate 
off" is obviously most explicit of all options, but I would rather 
consider a dummy certificate instead for now, as long as there are 
no other downsides.

> One advantage of the PSK path concept is that it provides a lot 
> of flexibility. It allows, for example, multiple applications to 
> each independently manage their own PSKs without the need to 
> coordinate changes to a single file (note that in this scenario 
> each application would want to use $ssl_psk_identity to check 
> the key).

On the one hand, it is a plus.  On the other - it is a nightmare 
when something goes wrong.  I would rather avoid such approach.

> stunnel uses a single file and seems to assume that 
> keys will be ASCII strings. Its format, for example, would not 
> allow NUL to appear in the string, as that would terminate the 
> key early and, at best, lead to a reduced key size.

Yes, and stunnel author considers this to be a feature, see 
https://www.stunnel.org/pipermail/stunnel-users/2015-October/005275.html.  
If you are targeting end-users, it might be actually easier to use 
sufficiently long printable keys then arbitrary binary strings.

> I might be mistaken, but wouldn't changing a certificate also 
> require reloading the configuration? Do you have some ideas on 
> how this could be done without requiring a reload?

Yes, changing a certificate requires a reload.  But the "path" 
concept is generally used in SSL where appropriate filesystem 
lookups are done on the fly, in contrast to loading a file into 
memory and then working with the data from memory.  Consider 
"openssl verify -CApath" vs. "openssl verify -CAfile".

Additionally, PSK keys look much more dynamic than certificates, 
as adding a user requires configuration changes.  With PKI, you 
don't need any certificate changes on the server to add a user.  
With PSK, you have to add a key to introduce a new user.

Overall, PSK seems to be very close to basic authentication, and 
it might worth looking how it is implemented in the auth_basic 
module (in short: the password file is searched on each request).  

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