Hi, On Mon, Oct 4, 2021 at 6:53 AM Gert Doering <g...@greenie.muc.de> wrote:
> Hi, > > (this is mainly for Arne and Selva, but I've decided to post it to > the list to raise awareness). > > OpenSSL 3.0 seems to bring "interesting" surprises with their provider > thingie, and openssl.cnf - not sure if this is at all relevant for > OpenVPN, but it sounds as if it might be. > I would consider those as user/admin errors though we can give an option to not load the default openssl.cnf or use a custom one at user's choice. For the internal provider we are working on, we'll be loading our provider and the default provider into a new libctx and using it in the SSL_CTX. But we'll still have many old-style API calls that does not take libctx or properties, and will continue to resolve from whatever providers are loaded implicitly into the default libctx (or explicitly through openssl.cnf). What I'm not sure about is whether we should also respect any default properties specified in openssl.cnf when we load our own providers. I think we should, but that again calls for the user to be careful when they edit openssl.cnf. IMO, in OpenVPN we should use our own customized openssl.cnf with minimal entries required for a preferred state that we want -- things like signature algorithms, ciphers etc could be set there. Then provide an option to load the user's config (or system-wide one) if they want to override it. Selva > Hello, > > TL;DR. Bad openssl config can break remote access to the system via SSH. > > OpenSSL 3.0 doesn't provide any crypto primitives itself. It is done via > the providers' mechanism. The provider should be loaded and activated to > make some algorithms and RNG available. > > The default provider is a bit special. If no providers are activated > explicitly, the default one is activated implicitly. (See details in > https://github.com/openssl/openssl/issues/16249). Its activation is > commented out in the config file. If anybody tries to activate a legacy > provider and doesn't uncomment the default provider activation, the system > becomes almost unsuitable for work and not remotely accessible anymore. > > I am pretty sure that there will be enough people who because either not > reading the documentation or just being in a hurry will turn the remote > accessibility off. > > To prevent it, the viable option is explicitly load the default provider in > openssh if necessary. > We can check if it is necessary in several ways. First, we can check if the > default or FIPS provider is already loaded. Second, we could check that any > algorithm (I'd prefer some of the AES-CTR family) is available, and load > the default provider if not, implying that it the selected algorithm is > implemented in the provider carrying also some sort of key exchange > algorithm, RNG, etc. I have a tentative patch for this purpose. > > There also may be an option to add an explicit switch > 'FallbackToDefaultProvider yes' to the openssh configuration. > > Please, any feedback is welcome. > > -- > Dmitry Belyavskiy > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-...@mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > ----- End forwarded message ----- > > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
