LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Packages
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Medium
  • Reported Version All
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: LEDE Project
Opened by Baptiste Jonglez - 30.07.2017
Last edited by Mathias Kresin - 28.08.2017

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

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.

Closed by  Mathias Kresin
28.08.2017 11:31
Reason for closing:  Fixed
Additional comments about closing:  

Fixed with ht tps://git.lede-project.org/3e35eb13ada3b 87e87cd108f9d459b9484446e9c

Magnus Kroken commented on 30.07.2017 18:51

The CA cert is accepted because the public key of the root certificate is trusted directly, instead of trusting its hash. See 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.

Baptiste Jonglez commented on 30.07.2017 20:32

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.

Magnus Kroken commented on 30.07.2017 20:47

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

diizzyy commented on 06.08.2017 11:36

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing