Re: Upgrading to OpenSSL 1.1.0

[Jeffrey Walton <noloader@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]

On Tue, Jan 16, 2018 at 6:36 AM, ummeegge <ummeegge(a)ipfire.org> wrote:
> ...
>>> Another point in here is IPFire uses currently the level 3 of --script-
>>> security for the RW " 3 -- Allow passwords to be passed to scripts via
>>> environmental variables (potentially unsafe)" which is important for some
>>> kinds of authentication methods but which has also been marked as unsafe and
>>> have also be again pointed out while the QuarkLabs and Cryptography
>>> Engineering LCC audit -->
>>> https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerAud
>>> its --> under "OVPN-08-1: OpenVPN configuration risks: --script-security 3"
>>> you can find there also OpenVPNs statements causing this topic.
>>
>> AFAIK we don't use any of those authentication methods. Or are we?
>
> Possibly all people which uses OpenVPN as a client on IPFire are rely to this auth method cause their VPN Provider sets usually "auth-user-pass-verify" directives. Since this option is not officially supported, i think their on their own...

Be careful of allowing users to be on their own if your goals are
security objectives. The results usually leave a lot to be desired.
>From NaCl's "Expert selection of default primitives"
(https://nacl.cr.yp.to/features.html):

    Most programmers using cryptographic libraries are not expert
    cryptographic security evaluators. Often programmers pass the
    choice along to users—who usually have even less information
    about the security of cryptographic primitives. There is a long
    history of these programmers and users making poor choices of
    cryptographic primitives, such as MD5 and 512-bit RSA, years
    after cryptographers began issuing warnings about the security
    of those primitives.

It may be a better idea to support users if that is what they demand.

If you are drop dead opposed to the support, then make it hard for
users to do it. Don't make it easy to do the insecure end-around. This
is part of the "easy to use correctly, hard to use incorrectly"
security design principal.

Sorry about the bikeshedding.

Jeff