"Tunnel-berlin" flavor firmware is not compatible with the bbb-vpn

[pmelange]

VPN03 and the BBB-VPN use openvpn-mbedtls and the new tunnel-berlin uses openvpn-openssl. This causes a problem when trying to use BBB-VPN with tunnel-berlin. edit(sarumpaet): You probably meant that the vpn03 hedy firmware image uses openvpn-openssl (which supports 1024 bit keys), and that the tunnel-berlin hedy firmware image uses openvpn-mbedtls (which does not allow 1024 bit keys).

daemon.err openvpn(bbbvpn)[3324]: VERIFY ERROR: depth=0, subject=C=DE, ST=East Germany, L=Berlin, O=Freifunk, OU=Individual Network Berlin e.V., CN=bbb-vpn, emailAddress=sven-ola@gmx.de: The certificate is signed with an unacceptable key (eg bad curve, RSA too short).

It is also not possible to install both openvpn-mbedtls and openvpn-openssl.

Since we have already started on the path to using mbedtls, would it make sense to support it with the bbb-vpn?

@booo would it be possible to set up the test-bbb-vpn to accept mbedtls connections? Also would it be possible to not require certs / have one universal cert? This way we would only need a bbb-vpn package.

@SvenRoederer Or does it make more sense to have the routers support both mbedtls and openssl (at least the 8M routers)? It looks like it should be possible #428

Either way, I feel we need to have a solution before the Hedy release.

[SvenRoederer]

When I once suggested to renew the BBB-VPN CA (to the ca.berlin.freifunk-code, added by an autoapprove-feature) this was vetoed.

To solve this issue I suggest for now:

opkg remove --force-depends openvpn-mbedtls opkg install openvpn-openssl

[pmelange]

This workaround was successful. We should probably change the HOWTO for the bbb-vpn to reflect this.

What other options are there to make the change to mbedtls as pain-free as possible for the end users?

[SvenRoederer]

What other options are there to make the change to mbedtls as pain-free as possible for the end users?

• changing the keys of the BBB-VPN (issued keys and new keys)
• patching "mbedtls" to accept 1024-bit keys

[ddmesh]

Hi, in Dresden we also have this problem to connect to berlin. It would be great if there is a solution for this except changing back to openssl. firmware uses webserver with mbedtls and we dont want to install openssl in addition to mbedtls. other certificates from airvpn are working perfectly. bye Stephan

[SvenRoederer]

think VPN03 and BBB-VPN have changed to 2k keys for new issued certs. This might become a nightmare to debug, why certain tunnels will work and other not, but it's a fix.

[booo]

We still have to make the change for VPN03 and we still have a lot of short keys out there. I think it still makes sense to patch mbedtls.

[pmelange]

Could this be the solution, or at least a pointer in the right direction?

https://tls.mbed.org/discussions/generic/how-to-enable-mbedtls-to-validate-certificates-with-rsa-1024

[torte71]

@pmelange : This would require a bigger modification to openvpn-mbedtls:

• replacing the currently used mbedtls_x509_crt_verify_info() with mbedtls_x509_crt_verify_with_profile() (or adding a call to) - which needs a quite different set of parameters
• adding an option to read the profile for 1024bit from a file (or have it compiled in) (At least, I didn't find any hint, that openvpn-mbedtls would already provide a way to pass a custom profile)

AFAIK, patching mbedtls to a smaller minimal keysize would be just a one-liner.

The first solution would be the elegant, intended way, but is definitely harder to understand and maintain than the more "hackish" second approach.

[sarumpaet]

I vote for using mbedtls in the firmware and patching it to support 1024 bit legacy certs.

Labeling this as "bug" as this is a classic regression from user perspective.

[booo]

I merged @sarumpaet patch for 1024 bits RSA. Based on the discussion this seems to be consensus.