On 13/04/17 15:37, Steffan Karger wrote: > On 13-04-17 15:09, David Sommerseth wrote: >> I'm however a bit puzzled of the "non-changes" (well, the indenting is >> changing, unless I'm blind to other changes) to --remote-cert-cu, >> --remote-cert-tls and --ns-cert-type. If we want to change the >> indenting, I think that should be kept in a separate patch, and keep >> --tls-cert-profile as a patch of its own. > > Ah, indeed. The indenting change is needed to make Github parse the rst > correctly. Feel free to remove the indenting changes and I'll send a > follow-up patch doing just that.
Thanks! I'll have a closer look and test the patch again. >> 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. For mbedtls, the biggest issue now is the lack of PKCS#11 and PKCS#12 support. For PKCS#11, that is moving forward as the Fedora mbedtls package now enables that feature. PKCS#12 seems to be a far harder nut to crack. > 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. And it is a big hassle for our users. The reason I now receive more noise about these things nowadays is actually that I've pushed forward for mbed TLS to actually be able to provide a somewhat functional OpenVPN package in Fedora. So the amount of OpenVPN users with mbed TLS suddenly got a considerable lift. Unfortunately, many of them are looking forward for OpenVPN switching back to OpenSSL. So being smart here, may actually make it more interesting for users to look more into mbed TLS later on. If all they remember from mbed TLS that it broke OpenVPN configurations, that's not a good "sales argument". So we do need to find a good compromise between modern security and our users, regardless of if they are Fedora users or not. Hence I think pushing forward for 'preferred' in v2.4 is too early. I agree we can do that in v2.5/git master though, as that does give us time to communicate this to users and perhaps even do something similar for the OpenSSL builds as well. And it is also a bit challenging to defend, at least for me, that mbed TLS based builds are more conservative and stricter on the security parameters than OpenVPN builds against OpenSSL - especially when the OpenVPN version itself is the same. I do understand and agree that it is needed to move forward, but that must be done in a way which doesn't alienate us with our users. And this is basically the same argument why James have moved OpenVPN 3 builds against mbed TLS also use the 'legacy' profile as default. My initial port from PolarSSL 1.3 to mbed TLS 2.3 for OpenVPN 3 did what you suggest, raise the security requirements. -- 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
