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-boun...@nginx.org] On Behalf Of Maxim
Dounin
Sent: Monday, June 05, 2017 1:40 PM
To: nginx-devel@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@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.
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
