Maxim,

I'm starting to get back to this now and wanted to follow up on your comments in http://mailman.nginx.org/pipermail/nginx-devel/2017-June/010247.html to see if you had a preference on when the PSKs should be read from the file. I believe we have two options:

1) At startup into a hash.
Advantages: Faster lookups, PSK file can be read-only by root, can warn on syntax errors
Disadvantages: Must reload to add/remove PSKs, more config options (for the hash max size and bucket size)

2) As needed. This is what was done in the last patch, but changed to no longer check for syntax errors at startup.
Advantages: Do not need to reload to add/remove users, can control access using groups
Disadvantages: Slower lookups (linear, but this can be improved using a RAM disk)

Thanks,

Nate

-----Original Message-----
From: nginx-devel [mailto:nginx-devel-bounces@nginx.org] On Behalf Of Maxim Dounin
Sent: Friday, June 30, 2017 6:58 AM
To: nginx-devel@nginx.org
Subject: Re: [PATCH 1 of 3] PSK: connection support

Hello!

On Thu, Jun 29, 2017 at 10:00:45PM +0000, Karstens, Nate wrote:

> Thanks for the comments. I'll try to start on those in a couple of
> days.

Just to make it clear: there is no need to hurry. Likely I won't be able to review new patches in at least a couple of weeks, so feel free to spend more time polishing the patches.

> My company uses Outlook/Exchange for email, so I don't think I'll be
> able to use hg email, do you have any other suggestions? Thanks also
> for your patience, I've used Git quite a bit but am new to Mercurial.

The "hg email" command can work with any SMTP server, including Exchange. Or you can ensure proper threading manually by using a "reply" function.

> Utkarsh sounds like he is trying to use PSK for TLS v1.3 session
> resumption. Given that each TLS connection could potentially result in
> a new PSK I think only reading them at startup could result in too
> many refreshes. I think there might be some benefit to the original
> approach in regards to storing each PSK in its own file in a
> designated directory. Benefits include:

TLS v1.3 session resumption uses PSK internally, but it is very different from internal usage point of view. It is handled well enough with existing session cache / session tickets mechanisms.

[...]

> > +ngx_int_t
> > +ngx_ssl_psk_file(ngx_conf_t *cf, ngx_ssl_t *ssl, ngx_str_t *file)
> > +
> > +{
>
> Style: extra empty line.
>
> > + ngx_int_t rc;
> > +
> > + if (SSL_CTX_set_ex_data(ssl->ctx, ngx_ssl_psk_index, file) == 0) {
> > + ngx_ssl_error(NGX_LOG_ALERT, ssl->log, 0,
> > + "SSL_CTX_set_ex_data() failed");
> > + return NGX_ERROR;
> > + }
> > +
> > + rc = ngx_ssl_psk_read(file, NULL, NULL, 0);
> > +
> > + return rc == 0 ? NGX_OK : NGX_ERROR; }

[...]

> > @@ -800,6 +810,12 @@
> >
> > }
> >
> > + if (ngx_ssl_psk_file(cf, &conf->ssl, &conf->psk_file)
> > + != NGX_OK)
> > + {
> > + return NGX_CONF_ERROR;
> > + }

Note: this calls ngx_ssl_psk_file() unconditionally, and
ngx_ssl_psk_file() also doesn't check if a file is configured. As a result, a configuration without ssl_psk_file fails.

--
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