Re: PSK Support
Hello! On Wed, Jun 14, 2017 at 01:10:55AM +, Karstens, Nate wrote: > OK, sounds good to me! I'll hopefully have some new patches > available in a couple of days. > > Any thoughts on using regular expressions to validate the format > of the password file and extract strings? Specifically, does any > string matching have to use regular expressions (protected by > NGX_PCRE), or is the use of regular expressions optional? In general nginx doesn't use regular expressions internally, as usually there are better ways to validate things. Also, it is expected to work fine without regular expressions, so using regular expressions to validate anything means that the feature won't be available without pcre compiled in. If you are looking for ways to simplify the patch, consider only preserving plain-text secrets, and/or using Base64 instead of hex (as there is standard ngx_decode_base64() function available). -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
RE: PSK Support
OK, sounds good to me! I'll hopefully have some new patches available in a
couple of days.
Any thoughts on using regular expressions to validate the format of the
password file and extract strings? Specifically, does any string matching have
to use regular expressions (protected by NGX_PCRE), or is the use of regular
expressions optional?
Nate
-Original Message-
From: nginx-devel [mailto:nginx-devel-boun...@nginx.org] On Behalf Of Maxim
Dounin
Sent: Tuesday, June 13, 2017 9:55 AM
To: nginx-devel@nginx.org
Subject: Re: PSK Support
Hello!
On Fri, Jun 09, 2017 at 03:40:15AM +, Karstens, Nate wrote:
> Maxim,
>
> OK, we can skip the patch for turning off the certificate warnings
> (and just use a dummy certificate) and just support a single PSK file.
>
> The {HEX} prefix seems OK. I think it would also be good to support an
> {ASC}. It is unlikely that anyone would have an ASCII-based PSK that
> starts with {HEX}, but using {ASC} would provide a way to make prevent
> that case.
If somebody want to use a key which starts with {HEX}, an obvious solution
would be to convert it to hex. Supporting an additional prefix for plain-text
keys might be an option too (in auth_basic it is called {PLAIN}, see
nginx.org/r/auth_basic_user_file), but I think that it would be good to
interpret non-prefixed keys in a way compatible with stunnel. So there will be
3 options:
identity:key
identity:{PLAIN}key
identity:{HEX}6b6579
> Also, instead of referring to text-based PSKs as ASCII, maybe they
> should be UTF8-encoded and referred to as {TXT}?
I would rather avoid saying anything about character encoding, much like nginx
does in most of the other places. The {PLAIN} seems to be neutral enough.
--
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
Re: PSK Support
Hello!
On Fri, Jun 09, 2017 at 03:40:15AM +, Karstens, Nate wrote:
> Maxim,
>
> OK, we can skip the patch for turning off the certificate
> warnings (and just use a dummy certificate) and just support a
> single PSK file.
>
> The {HEX} prefix seems OK. I think it would also be good to
> support an {ASC}. It is unlikely that anyone would have an
> ASCII-based PSK that starts with {HEX}, but using {ASC} would
> provide a way to make prevent that case.
If somebody want to use a key which starts with {HEX}, an obvious
solution would be to convert it to hex. Supporting an additional
prefix for plain-text keys might be an option too (in auth_basic
it is called {PLAIN}, see nginx.org/r/auth_basic_user_file), but I
think that it would be good to interpret non-prefixed keys in a
way compatible with stunnel. So there will be 3 options:
identity:key
identity:{PLAIN}key
identity:{HEX}6b6579
> Also, instead of referring to text-based PSKs as ASCII, maybe
> they should be UTF8-encoded and referred to as {TXT}?
I would rather avoid saying anything about character encoding,
much like nginx does in most of the other places. The {PLAIN}
seems to be neutral enough.
--
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
RE: PSK Support
Maxim,
OK, we can skip the patch for turning off the certificate warnings (and just
use a dummy certificate) and just support a single PSK file.
The {HEX} prefix seems OK. I think it would also be good to support an {ASC}.
It is unlikely that anyone would have an ASCII-based PSK that starts with
{HEX}, but using {ASC} would provide a way to make prevent that case.
Also, instead of referring to text-based PSKs as ASCII, maybe they should be
UTF8-encoded and referred to as {TXT}?
Nate
-Original Message-
From: nginx-devel [mailto:nginx-devel-boun...@nginx.org] On Behalf Of Maxim
Dounin
Sent: Wednesday, June 07, 2017 1:13 PM
To: nginx-devel@nginx.org
Subject: Re: PSK Support
Hello!
On Wed, Jun 07, 2017 at 05:02:52AM +, Karstens, Nate wrote:
> 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;")?
In most cases, normal users won't need PSK at all, or will use it combined with
certificates anyway. Describing in the documentation that "if you need to use
PSK only, you still have to configure a certificate" doesn't looks like a big
problem to me.
Note well that there is a side problem with "listen ... ssl" used in server
block but no ssl_certificate configured for the server.
As of now, it is not reported during configuration parsing and may result in
non-obvious behaviour in some cases, see ticket #178
(https://trac.nginx.org/nginx/ticket/178). This is a separate problem though,
and it can't be fixed with the changes suggested.
On the other hand, properly fixing it will greatly improve user experience in
many cases, including PSK.
> 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?
I don't think that supporting multiple files is a good idea, a single one
should be enough.
Possible alternative names:
- "ssl_psk_secrets", similar to the one used by stunnel;
- "ssl_pre_shared_keys".
Not sure if these are better though.
> 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?
We can consider providing an alternative form to allow arbitrary keys, e.g., by
using hex-encoded keys. This can be done using some explicit prefix, something
like this:
identity:key
identity:0x6b6579
identity:{HEX}6b6579
(The last variant is in line with "{scheme}data" syntax as used in
auth_basic_user_file. Not sure if we need it here, just "0x"
might be easier.)
--
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
Re: PSK Support
Hello!
On Wed, Jun 07, 2017 at 05:02:52AM +, Karstens, Nate wrote:
> 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;")?
In most cases, normal users won't need PSK at all, or will use it
combined with certificates anyway. Describing in the
documentation that "if you need to use PSK only, you still have to
configure a certificate" doesn't looks like a big problem to me.
Note well that there is a side problem with "listen ... ssl" used
in server block but no ssl_certificate configured for the server.
As of now, it is not reported during configuration parsing and may
result in non-obvious behaviour in some cases, see ticket #178
(https://trac.nginx.org/nginx/ticket/178). This is a separate
problem though, and it can't be fixed with the changes suggested.
On the other hand, properly fixing it will greatly improve user
experience in many cases, including PSK.
> 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?
I don't think that supporting multiple files is a good idea, a
single one should be enough.
Possible alternative names:
- "ssl_psk_secrets", similar to the one used by stunnel;
- "ssl_pre_shared_keys".
Not sure if these are better though.
> 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?
We can consider providing an alternative form to allow arbitrary
keys, e.g., by using hex-encoded keys. This can be done using
some explicit prefix, something like this:
identity:key
identity:0x6b6579
identity:{HEX}6b6579
(The last variant is in line with "{scheme}data" syntax as used in
auth_basic_user_file. Not sure if we need it here, just "0x"
might be easier.)
--
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
RE: PSK Support
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 +, 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 ver
Re: PSK Support
Hello!
On Mon, Jun 05, 2017 at 02:08:15PM +, 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
RE: PSK Support
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-boun...@nginx.org] On Behalf Of Maxim Dounin Sent: Monday, June 05, 2017 8:09 AM To: nginx-devel@nginx.org Subject: Re: PSK Support Hello! On Thu, Jun 01, 2017 at 05:20:53PM +, 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://ngi
Re: PSK Support
Hello! On Thu, Jun 01, 2017 at 05:20:53PM +, 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-nginx-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@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
