mkrkn:

The CA cert is accepted because the public key of the root certificate is trusted directly, instead of trusting its hash. See [[https://www.entrust.com/need-sha-2-signed-root-certificates/|Do You Need SHA-2 Signed Root Certificates?]] for more details.

Google, Microsoft and Mozilla all stopped supporting HTTPS certificates with SHA-1 digests in their web browsers early this year. Causing a SHA-1 collision in order to impersonate a legitimate server is now considered within reach of well funded attackers. This is the same problem, just in the context of VPN instead of HTTPS.

The Easy-RSA script commonly used to manage personal OpenVPN certificate authorities has issued certificates with SHA-256 digests for several years. In addition, OpenVPN does not rely on the traditional network of public root CAs - each OpenVPN service provider, be it big commercial or one personal server, runs their own root CA(s). As such there is nothing preventing a provider from issuing new certificates - no fees, no need to wait for CA compatibility.

The actual problem is servers/clients using certificates that are considered weak, something LEDE can't fix. We can provide interoperability with them, but by doing so we also remove the incentive to fix the issue, and prolong the lowered security.

In this case I think security and correctness should weigh higher than interoperability, as the security implications are real and have been demonstrated by researchers. There isn't a fine-grained way to configure this (e.g. you can't configure a single OpenVPN client to only accept certs with SHA-256 digests if you globally accept certs with SHA-1 digests), so by doing this we lower the security of all LEDE users, even if their specific server/provider uses strong certificates.

bjonglez:

I understand the rationale, and I'm all for more security.

However, as a LEDE/openvpn user, I probably don't have access to the openvpn server (for instance it might be a commercial VPN provider). So it is really frustrating to have a broken service without any practical way to fix it.

My main complaint is that it introduces a non-compatible change in lede-17.01. As a compromise, I think it makes sense to:

• re-enable SHA1 in lede-17.01
• leave SHA1 disabled in trunk
• clearly mention in the release notes of the next LEDE/OpenWRT major release that mbedtls no longer supports SHA1 signatures.

mkrkn:

Maintaining feature compatibility in release branches does make sense, I think your suggested compromise is very reasonable.

diizzyy:

Agreed, keep compatibility in 17.01.
Drop it for everything else.

bjonglez:

SHA1 has been re-enabled in lede-17.01: https://git.lede-project.org/?p=source.git;a=commit;h=3e35eb13ada3b87e87cd108f9d459b9484446e9c