On 14/04/17 11:16, Steffan Karger wrote: > 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?
I think it's needed to improve some details in the man page and Changes.rst. Perhaps also extend the man page to state that --tls-cert-profile is currently a NOOP builds against OpenSSL? For git master (future v2.5) I have no issues having 'preferred' being the default. And we need to start announcing that things will be stricter in v2.5 already now. But for v2.4 I think we should go for 'legacy' as the default. > 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. Fedora was just an example of what was needed to avoid a rebellious revolution against the package maintainer. But it illustrates the trickiness of pushing such changes too quickly to a user base. Hence, how I see it, for the whole OpenVPN user base regardless of OS/distro, to have legacy being the default for v2.4 users. Which also aligns well with the default chosen for the OpenVPN 3 user base (which includes all OpenVPN Connect users). But be sure, I think we need to move towards 'preferred'. But doing it in a good way for all. -- kind regards, David Sommerseth OpenVPN Technologies, Inc
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
