PSK Support

[Karstens, Nate]

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.

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. 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?

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). 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.

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?

I agree on the proxy_ssl_* directives; the same could probably be said for the mail and stream SSL modules.

Regards,

Nate

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

Hello!

On Thu, Jun 01, 2017 at 05:20:53PM +0000, Karstens, Nate wrote:

> Greetings,
>
> I'm about push 3 patches that add support for PSK TLS cipher suites to
> nginx and thought it would be good to discuss the feature itself in a
> separate thread.
>
> First, PSK support is useful in certain environments that are not
> conducive to a full public key infrastructure. The environment I'm
> personally working with is the recreational boating market; we are
> developing a new industry standard that relies on HTTPS, secured by
> PSK, for much of its underlying security protocol. I think this would
> also be useful to the IoT market. A quick search shows that some other
> users have been interested in this feature:
>
> https://forum.nginx.org/read.php?2,272443,272443
> https://stackoverflow.com/questions/22513641/pre-shared-keys-tls-psk-n
> ginx-configuration

I have mixed feelings about PSK.  On the one hand, it is expected to be better for constrained devices and also may have various performance benefits for internal connections.  On the other hand, using a shared key is a big step backwards compared to public-key cryptography.

> After applying the patches, one can enable PSK support by adding a few
> directives to their nginx.conf:
>
> 1) "ssl_nocert" -- This disables checks for a certificate within
> nginx. By default these checks are enabled because most users will
> need a certificate. This is analogous to the "-nocert"
> option in the OpenSSL s_server.
> 2) "ssl_psk_path" -- This is a local folder that contains all of the
> valid PSKs. Each file in the folder is loaded into memory as a PSK,
> and its file name is used as the PSK identity. When the client
> connects it specifies the identity of the PSK it is using for the
> connection. The server looks up the key using hash of the loaded PSKs
> and if the keys match then the TLS handshake is successful. Note that
> the identity of the PSK is made available in the variable
> $ssl_psk_identity.
> 3) Add some PSK ciphers to the "ssl_ciphers" directive.

Some comments, in no particular order:

- the "ssl_nocert" directive looks strange / unneeded, there
  should be a better way to do this (ssl_certificate with a
  special value "off"? just assume a certificate is not needed if
  there are PSK secrets? always require a certificate, and let
  users who don't need specify a dummy one?);

- "ssl_psk_path" seems to be overcomplicated, and yet non-flexible
  as any change to keys requires configuration reloads;

- the only server software with PSK support seems to be stunnel,
  it might be good to be compatible with the form it uses for PSK
  secrets (a file with "IDENTITY:KEY" lines);

- probably eventually there should be a proxy_ssl_* counterpart,
  though it is perfectly ok to don't have it for now.

--
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.