On Wed, Sep 06, 2017 at 01:46:06PM +0000, Karstens, Nate wrote:
Yes, I see what you were saying now, sorry for the confusion. Your updates look good.
How do you plan to get additional feedback? Maybe at nginx.conf? Our particular use case is more of an embedded environment, so our security constraints are different from a high traffic web server. Perhaps we can extrapolate the best approach for that environment given what we know?
There are no specific plans, though usually people tend to provide feedback on patches they are interested in. That is, if there are people interested in PSK support, eventually there will be some feedback.
As I see it, we have a few alternatives:
- Read the file from the PSK worker process (as is being done
in the current patch) 2) Read the file when the configuration is loaded and cache results in memory (file only needs to be read by master process) 3) Allow the user to choose between 1 and 2 (using a config file setting) 4) Adding encryption to PSK file (encryption key is loaded when configuration is loaded and PSK file is decrypted by worker process)
Can you think of any others?
The only alternatives I would consider at this point are (1) and (2). Everything else looks overcomplicated.
The main disadvantage of the second option is that you have to reload the configuration file whenever a PSK is added/removed/changed, right? Can you help me understand the performance implications of reloading the configuration file? If severe, maybe those performance implications could be mitigated by functionality specific to the environment the server is operating in? For example, in an environment with thousands of users maybe the administrators could institute a policy of updating the PSK file and reloading the configuration only once every 5 minutes? Other, less complicated environments could operate without any additional functionality.
Yes, basically this is the only downside of the (1) approach - to change PSK list you need to reload a configuration. This applies to many aspects in nginx though, and I don't actually think that this is a problem. If a particular setup requires changing PSK keys at a high rate, using client certificates might be a better option. And that's why I think it might be better to switch back to (2), which seems to be slightly more secure.