PSK Support

Wed Jun 7 05:02:52 UTC 2017

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;")?

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?

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?

Thanks,

Nate

-----Original Message-----
From: nginx-devel [mailto:nginx-devel-bounces at nginx.org] On Behalf Of Maxim Dounin
Sent: Monday, June 05, 2017 1:40 PM
To: nginx-devel at nginx.org
Subject: Re: PSK Support

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/
_______________________________________________
nginx-devel mailing list
nginx-devel at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.