mdounin at mdounin.ru
Mon Jun 5 13:09:16 UTC 2017
On Thu, Jun 01, 2017 at 05:20:53PM +0000, Karstens, Nate wrote:
> 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:
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
> 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.
More information about the nginx-devel