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-bounces@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 +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
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
