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:[email protected]] On Behalf Of Maxim
Dounin
Sent: Wednesday, June 07, 2017 1:13 PM
To: [email protected]
Subject: Re: PSK Support
Hello!
On Wed, Jun 07, 2017 at 05:02:52AM +0000, 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
[email protected]
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
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-devel
