On Thu, Oct 21, 2021 at 8:52 AM Arne Schwabe <a...@rfc2549.org> wrote:
> Am 20.10.21 um 20:19 schrieb Selva Nair: > > Hi, > > > > Not a code review but a general comment as this is a new option that > > warrants some discussion. > > > > On Tue, Oct 19, 2021 at 2:32 PM Arne Schwabe <a...@rfc2549.org > > <mailto:a...@rfc2549.org>> wrote: > > > > This allows OpenVPN to load non-default providers. This is mainly > > useful for loading the legacy provider with --provider legacy:default > > > > > > While this format looks okay, we need to consider a few things to get > > this option right and possibly extensible in future without causing a > > regression. > > > > (i) Provider name may not be a simple word like legacy -- could also be > > the path to a shared object with possible embedded space in the path > > name. A single option with optional quotes, picked apart using ":" as > > separator can still work. > > > > Ideally I would have preferred space separated provider names with > > each quoted if needed, but the format proposed here may be easier to > > parse. Need clear documentation, though. > > > Yeah using : was easier to parse since I need otherwise to setup an > array or a list to store the parameter but it is doable. I was just > hoping that nobody would use a : in the provider name. > Use of '.' in the name is the recommended method to have a namespace in the provider name and reduce chances of name conflict. No one may use ':' and filenames are unlikely to contain ':' as its not legal in some platforms. That said, adding an array or list is easier than it looks. We have several options that use an array or list and the code overhead is small. > > > (ii) We may want to attach some meaning to the order in which providers > > are specified. > > That would be mostly a documentation thing to explain that the providers > are loaded the in order specified with that option. > Here is why: > > > > When multiple providers implement the same method (say, KEYEXCH), there > > is no guarantee in OpenSSL as to which will get used. Unless a property > > query like "?provider=my-fast-aes" is also used. Here the prefix "?" to > > mean preferred but not exclusive. In cases like an pkcs11 token > > provider, one would need to say the opposite like "?provider=default" to > > ensure default is preferred and the token provider is to be used only > > when required -- say when the key is in a token. Same would be the case > > with our proposed built-in "external-key provider" which should be used > > only for certain operations that handle the external key. > > > > How this relates to the --provider option is like this: in some cases we > > want to know which provider the user prefers. Instead of hard-coding the > > preferred provider to "default" which the user may not even want to > > load. We could state that the first provider specified will become the > > preferred one when there are multiple choices for a method or when a > > preferred fallback is required. In that case the option for legacy would > be > > > > --provider default:legacy > > > > And, if this option is absent, we take it to mean that the "default" > > provider should be loaded. > > I would not explicitly load the default provider then but rather inherit > what the system gives us. If the system wide config loads fips we should > not load default instead. > IMO, this idea that OpenSSL folks have that just adding a "fips=yes" plus a few lines in the config can make the application FIPS enabled is far-fetched. In reality OpenVPN will have to be recompiled with some changes to make it FIPS compliant. At that point one can also change what providers are loaded by default. I was thinking of having a load_providers() function called early -- say in options-post-process stage where we load (i) default provider (ii) providers specified in --providers option This adds much certainty to what is available. A FIPS-enabled OpenVPN can change this or we could have a --fips option that changes this. No dependency on system-wide config file and those who need legacy only need to just specify "--providers legacy" In addition, one could automatically load "legacy" if any of the options indicate its need -- like NTLM auth for proxy or BF-CBC in --data-ciphers etc. In situations where it cannot be inferred from options, user will have to use --providers legacy, though. It may be necessary to call this load_providers() also to process options like --show-ciphers and similar. Selva
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
