Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#942 - openvpn-mbedtls no longer accepts SHA1 certificates #5921

Closed
openwrt-bot opened this issue Jul 30, 2017 · 5 comments
Closed

FS#942 - openvpn-mbedtls no longer accepts SHA1 certificates #5921

openwrt-bot opened this issue Jul 30, 2017 · 5 comments
Labels

Comments

@openwrt-bot
Copy link

openwrt-bot commented Jul 30, 2017

bjonglez:

Since the update of mbedtls to version 2.5.1 (in both trunk and lede-17.01), the openvpn client no longer accepts SHA1 certificates.

This gives the following error when the client tries to connect:

openvpn(client)[1897]: TLS: Initial packet from [AF_INET]XXX:1194, sid=c5d9be97 6dc8ee7f
openvpn(client)[1897]: VERIFY OK: depth=1, C=FR, ST=XX, L=XX, O=XX, OU=openvpn, CN=openvpn-ca, ??=XX, emailAddress=abuse@XX
openvpn(client)[1897]: VERIFY ERROR: depth=0, subject=C=FR, ST=XX, L=XX, O=XX, OU=openvpn, CN=server, ??=XX, emailAddress=abuse@XX: The certificate is signed with an unacceptable hash.
openvpn(client)[1897]: TLS_ERROR: read tls_read_plaintext error: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
openvpn(client)[1897]: TLS Error: TLS object -> incoming plaintext read error
openvpn(client)[1897]: TLS Error: TLS handshake failed

Both the CA cert and the server cert are RSA4096 with SHA1 signature. Strangely, the CA cert is accepted but the server cert is not.

This is similar to FS#405, but I think it's overkill to disallow SHA1 certs: I guess there are lots of servers out there still using SHA1.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 30, 2017

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.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 30, 2017

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.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 30, 2017

mkrkn:

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

@openwrt-bot
Copy link
Author

openwrt-bot commented Aug 6, 2017

diizzyy:

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

@openwrt-bot
Copy link
Author

openwrt-bot commented Aug 25, 2017

bjonglez:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant