From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Upgrading to OpenSSL 1.1.0 Date: Tue, 16 Jan 2018 13:02:27 +0000 Message-ID: <1516107747.3647.117.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5628040922437651515==" List-Id: --===============5628040922437651515== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Jeffrey, that is some good idea, however I do not see how we can realise that easily a= nd 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=3Dnetwork.git;a=3Dtree;f=3Dconfig/vpn/security-po= licies;h=3D57c18b7e74d8e108195e829aa0d1816c296cf05a;hb=3DHEAD 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 t= he 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 pref= er to use. On Tue, 2018-01-16 at 07:34 -0500, Jeffrey Walton wrote: > On Tue, Jan 16, 2018 at 6:36 AM, ummeegge wrote: > > ... > > > > Another point in here is IPFire uses currently the level 3 of --scrip= t- > > > > 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 uns= afe > > > > and > > > > have also be again pointed out while the QuarkLabs and Cryptography > > > > Engineering LCC audit --> > > > > https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEn= gin > > > > eerAud > > > > its --> under "OVPN-08-1: OpenVPN configuration risks: --script-secur= ity=20 > > > > 3" > > > > you can find there also OpenVPNs statements causing this topic. > > >=20 > > > AFAIK we don't use any of those authentication methods. Or are we? > >=20 > > 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... >=20 > 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): >=20 > Most programmers using cryptographic libraries are not expert > cryptographic security evaluators. Often programmers pass the > choice along to users=E2=80=94who 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. >=20 > It may be a better idea to support users if that is what they demand. >=20 > 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. >=20 > Sorry about the bikeshedding. Please keep the feedback coming. The more eyeballs we get on these matters, t= he better. Best, -Michael >=20 > Jeff --===============5628040922437651515== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxwZDkrTUFDZ2tRZ0hudy8yK1EKQ1FjZDZ3LytJUXBmREtXTnVr R3lUN2o4UDZoUzJ1L1J5MjNwenFlZ2RRQVdBYTVmVmphYWRlQmR6NG5sSS9wQQpQV0VsZU5CZEZY MGNDTnEvdVJOM0lWeTNEWWorb1RIaC9TdVd4clAxdjd3Qk5ZNm1udGFISmJBbUFrcHB4YzE2CkJL UUY5eUxJalVsd29IaTdQRkdvS3VCZ2VvMW44R2tQaWRVTGJ6R21sNFJIVmovN3VCRVNRS0dVQTkz Ujl3SzgKZzJuZG0vQ0lmYzdhVVg2MVNBSUdyMTdLdlBzc1ExL0RSQk56YUVSNkNnVE9WVW43UkJa eWUzUVBoVy9SWW5ESgo3L25JR2xnb1h3Nm92Q0hmYkg3dDBaL0VYaExOMUwveVN0RlFhQTVwWGIv a013Z2tmbFpXWlphMUdoMEg1d1pXCmFnbmN5ODgwa1lzd3JuMm9zd1BSbmZML1ZLNWZ5MTRpdHUx UEtFR3pLeURnY0FmRDhpc3B6eTcxVUQ0b2ZwU20KbHk2dVlCTE83a2dPOXRtSDJ5dFNFd3UzSkc1 TnJEeTdGL3ltYm42Q1kxNzZOSVJreW94aW5ZbDk4Wi9jdzhwcQpSY3A0ZGpxeW5jd05KODFSaUE4 QjIrcFVrVGErc2djTzBDbjZsQnRTcHhEZkFpaGFJRGV2T2RJbGs4ekZWTkxCCllnZ25iMTdZaCt2 ZkM2MlJ4VnVHa0o4TmxBdHM0OU9GSVM0a3lDWVhDbVJmK1BKZ1dsemhjelZHY2hLV3I5WTUKdURN WFI0aEVhZldwaWtuMEU0dEJPUWFyNTBVK3h5cGg1WnRBMnJEZTkyb3N3QnJUTi9DV3FISVlKbFha cGZTdApmSTFMMXd6VTRaaE82QTV0K1E0Q1crM3R4ajZSanI4UkdWT3Eybm9uVTI0RGtHSGlLbjQ9 Cj0rQnlsCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============5628040922437651515==--