[PATCH] [PATCH 4 of 4] SSL: add identity hint config directive

[Maxim Dounin]

Hello!

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:
> 
> 1) 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.

-- 
Maxim Dounin
http://nginx.org/