Hello Jeffrey,
that is some good idea, however I do not see how we can realise that easily and without breaking anything in the current user interface.
In IPFire 3 we have decided to introduce so called "Security Policies":
https://git.ipfire.org/?p=network.git;a=tree;f=config/vpn/security-policies;...
We provide at least two ones that are updated with the system.
One policy is called "system" which is pretty much the most-compatible one and uses good and string ciphers. If we would ever consider one of them as broken, we would remove it from that list. Of course the system would always prefer the strongest option it can negotiate with the other peer.
The performance option uses only strong ciphers but for example with smaller key sizes like AES128 instead of 256. And only SHA256.
We have considered some compatibility option before but I don't want to tempt users to always select that.
Of course the CLI allows to create own policies with what ever you would prefer to use.
On Tue, 2018-01-16 at 07:34 -0500, Jeffrey Walton wrote:
On Tue, Jan 16, 2018 at 6:36 AM, ummeegge ummeegge@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/QuarkslabAndCryptographyEngin eerAud 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.
Please keep the feedback coming. The more eyeballs we get on these matters, the better.
Best, -Michael
Jeff