Hi, On 13-04-17 18:40, David Sommerseth wrote: > On 13/04/17 15:37, Steffan Karger wrote: >> On 13-04-17 15:09, David Sommerseth wrote: >>> On a more generic note to this patch. I wonder if we should keep >>> "legacy" the default in the v2.4 branch. In the Fedora 26 (and >>> Rawhide/27) builds I had to do something similar [1] to keep users >>> happy. As OpenVPN isn't ready for OpenSSL v1.1, I had to switch to mbed >>> TLS. Unfortunately that haven't been as successful as I really hoped it >>> would be, but that's an entirely different story (and mail thread). As >>> long as the Fedora builds need to be built with mbed TLS, I will need to >>> ensure 'legacy' is the default there for a while. For the coming Fedora >>> Rawhide (which will be F28), I can make some announcements preparing >>> users to move to stricter defaults. >>> >>> [1] >>> <http://pkgs.fedoraproject.org/cgit/rpms/openvpn.git/tree/0001-workaround-Allow-weaker-RSA-keys-and-MD-algorithms-i.patch?h=f26> >> >> The current mbed TLS builds already reject legacy crypto (except the >> fedora packaged build, apparently). With this patch users have the >> ability to use legacy stuff again, but I would prefer to not go any >> further than that. I think we should encourage people to drop the >> legacy. Just like the browser vendors are doing. > > I do agree. But the pain as a package maintainer is quite noticeable > when you're getting complaints about configurations this breaks. In > fact, I got quite some dissatisfied remarks even for moving from 2.3 to > 2.4 on the OpenSSL builds (F25 + EPEL) - as that also broke some setups > - mostly due to our option parser now doesn't ignore configuration > errors any more or we actually implement the dual stack IPv4/IPv6 > properly on the transport side. > > [..snip..] > >> And for Fedora, they chose to experience intense pain when they chose to >> go for OpenSSL 1.1 this fast, that's their problem I guess... If they >> want to be that cutting edge, they should also stop using legacy crypto. >> And otherwise, it will be a simple patch in the fedora packaging. > > Well, they do make things move forward fast. And they do a lot of work > to get upstream projects moving towards OpenSSL 1.1. As there is a > major Fedora release roughly every 6 months, it is a fast moving target. > > But Fedora users as side, they know each major release is a huge step > forward in many areas. For most OpenVPN users, regardless of OS or > distro, they are used to the more sloppy legacy crypto support of > OpenSSL. So enforcing a stricter set of crypto parameters in OpenVPN > v2.4 only on mbed TLS seems a bit odd to me.
I agree - which is why I plan to add similar behaviour to the OpenSSL builds. I'm convinced by the argument to better aligning OpenSSL and mbed TLS behaviour, so I agree that we should default to 'legacy' as long as the OpenSSL counterpart is missing. Do you prefer a v3? The thing I still don't buy is that we have to jump through hoops because Fedora pushes openssl 1.1 (even though 1.0.2 is fine and supported and all), but we have to keep enabling deprecated crypto *by default* that people should not be using anymore, and can easily re-enable with a --enable-old-cruft flag if they really want to. -Steffan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
