OpenVPN update from 1.1.21 to 1.1.22 (Google Play)

[gkuenning]

1.1.23 fails for me as well.

[gkuenning]

Hi,
OpenVPN Connect for Android already supports "legacy" mode, but it goes as back as RSA with 1024 bits keys.

Providing a workaround to still accept MD5 basically means opening a (big) security hole and that is not really acceptable.

I know it can be troublesome, but servers still using MD5 should *really* upgrade to something stronger.
MD5 has been broken for years now and supporting it means being unprofessional towards our users.

However, this is different from the bug discussed by the OP of this post. I am glad to hear that the original problem was solved by 1.1.23.

Cheers,

Unfortunately it fails even if you don't use MD5. My certificate is 1024-bit RSA, SHA1 with RSA encryption as the signature algorithm. And 1.1.23 doesn't work. 1.1.17 does.

[openwhat]

Same here, I don't use MD5.

A few Server settings I use:

- Authorization Mode: TLS
- Extra HMAC authorization (tls-auth / tls-crypt): Incoming Auth (0)
- Legacy/fallback cipher: AES-128-CBC
- Auth digest: SHA1
- Compression: LZO

[TinCanTech]

If you use your own VPN try making a new PKI with the correct settings.

EastRSA comes with default settings which should be fully compatible, let us know how it goes.

If you are using a public VPN Service tell them their certificate bundle is out of date.

[ordex]

Can you also make sure certificates, CA and CRL (if used) are not expired? What is the exact message reported in the log?
Generally speaking, mbedTLS is simply trying to stick to the currently non-broken settings (whatever they are - which means not just the signature algorithm), therefore it's very possible that you are using something outdated.
The solution recommended by tincantech is probably the one that would take you to a safe spot.

[ordex]

Same here, I don't use MD5.

A few Server settings I use:

- Authorization Mode: TLS
- Extra HMAC authorization (tls-auth / tls-crypt): Incoming Auth (0)
- Legacy/fallback cipher: AES-128-CBC
- Auth digest: SHA1
- Compression: LZO

This is your VPN configuration. When I mentioned MD5 I referred to the algorithm used to sign your certificates by your CA.

[openwhat]

Thanks for the help gents!
It's all working now with OpenVPN Connect for Android 1.1.23

I grabbed the new EasyRSA (3.0.3) and generated all new certs and keys.
When I compared with the old stuff it seems I indeed used Server and Client certs with MD5 signature hash-algorithm.
The new generated certs are all sha256.

Problem solved.

[openwhat]

Oh, one more question.

It seems client download speed has dropped a bit.
From approx. 18 Mbps to 11 Mbps.
I didn't change anything in the VPN config, only new certificates and keys.

Is this as expected? (Increased CPU load because of new certs and keys.)

[gkuenning]

If you use your own VPN try making a new PKI with the correct settings.

EastRSA comes with default settings which should be fully compatible, let us know how it goes.

If you are using a public VPN Service tell them their certificate bundle is out of date.

You're joking, right? I should redeploy the entire VPN because of this bug?

[gkuenning]

Same here, I don't use MD5.

A few Server settings I use:

- Authorization Mode: TLS
- Extra HMAC authorization (tls-auth / tls-crypt): Incoming Auth (0)
- Legacy/fallback cipher: AES-128-CBC
- Auth digest: SHA1
- Compression: LZO

This is your VPN configuration. When I mentioned MD5 I referred to the algorithm used to sign your certificates by your CA.

Yes but I already posted evidence from my own certificate, which uses SHA1.

[ordex]

Yes but I already posted evidence from my own certificate, which uses SHA1.

I believe I have missed that. Was it here in this thread? If your cert is signed with SHA1 there might be something different to look at. IT would be interesting to inspect the cert and CA.

[dazo]

Just to clarify one important detail, as I'm not sure if there is a confusion or not.

- Auth digest: SHA1

This line does NOT mean the certificate is not signed using an MD5 based signature.

Please check the output of:

Code: Select all

    $ openssl x509 -in $CERTIFICATE_FILE -noout -text | grep "Signature Algorithm"

Make sure you check the CA certificate, as well as the server and client certificates.

And regarding ...

You're joking, right? I should redeploy the entire VPN because of this bug?

If you are using MD5 certificates, you should definitely do exactly that. More details can be found in these few tweets from the @OpenVPN account: https://twitter.com/OpenVPN/status/899604229240877056

[dazo]

Oh, one more question.

It seems client download speed has dropped a bit.
From approx. 18 Mbps to 11 Mbps.
I didn't change anything in the VPN config, only new certificates and keys.

Is this as expected? (Increased CPU load because of new certs and keys.)

That seems to be a bit too much drop, to be honest. But there are many factors influencing the throughput. The certificate's public key length plays a role to a certain degree, but that is only used when establishing the session encryption keys for the tunnelled network traffic. But a few hints are to look at what kind of --cipher and --auth algorithm you use. Those have a far more massive impact - when otherwise ignoring the link quality between the client and server. By the way, which version does your OpenVPN server run?

Prefer GCM based ciphers if you can, as that gives the least packet overhead and does decryption and packet authentication in a single crypto operation. if you need to use a CBC based cipher, you should use --auth SHA1 (default) or --auth SHA256. Using SHA1 for --auth is considered safe, as SHA1 have no known cryptographic weaknesses when doing HMAC operations. SHA1 adds 20 bytes to each packet sent over the Internet link. SHA256 adds 32 bytes. And if you use SHA512, that adds 64(!) bytes and does not give any real security gain over SHA256.

[gkuenning]

Just to clarify one important detail, as I'm not sure if there is a confusion or not.

- Auth digest: SHA1

This line does NOT mean the certificate is not signed using an MD5 based signature.

Please check the output of:

Code: Select all

    $ openssl x509 -in $CERTIFICATE_FILE -noout -text | grep "Signature Algorithm"

Make sure you check the CA certificate, as well as the server and client certificates.

That's the issue. I only checked my CA certificate; the server has an MD5 certificate.

And regarding ...

You're joking, right? I should redeploy the entire VPN because of this bug?

If you are using MD5 certificates, you should definitely do exactly that. More details can be found in these few tweets from the @OpenVPN account: https://twitter.com/OpenVPN/status/899604229240877056

That depends entirely on why one is using a VPN. I don't give a hoot about encryption quality, and very little about the risk of strangers joining my VPN. For me it's all about routing.

Nevertheless I'll probably upgrade over the holidays when I have access to all the machines involved.

[TinCanTech]

If you use your own VPN try making a new PKI with the correct settings.

EastRSA comes with default settings which should be fully compatible, let us know how it goes.

If you are using a public VPN Service tell them their certificate bundle is out of date.

You're joking, right? I should redeploy the entire VPN because of this bug?

It is not a bug .. And it is your PKI not your VPN.

Unfortunately it fails even if you don't use MD5. My certificate is 1024-bit RSA, SHA1 with RSA encryption as the signature algorithm. And 1.1.23 doesn't work. 1.1.17 does.

It doesn't work because your certificate not up to scratch with modern security ..

That depends entirely on why one is using a VPN. I don't give a hoot about encryption quality, and very little about the risk of strangers joining my VPN. For me it's all about routing.

Everyone else is concerned about their security .. It is the P in V.P.N.

There are two parts to Openvpn .. the network side and the security side ..
The network side is a work of art when you understand how it is done.

The security side is almost but not completely down to the SSL Library in use ..
Many decisions regarding it's implementation are resolved upstream not by OpenVPN.

ch-ch-ch-ch-Changes

[ordex]

Just to clarify one important detail, as I'm not sure if there is a confusion or not.

- Auth digest: SHA1

This line does NOT mean the certificate is not signed using an MD5 based signature.

Please check the output of:

Code: Select all

    $ openssl x509 -in $CERTIFICATE_FILE -noout -text | grep "Signature Algorithm"

Make sure you check the CA certificate, as well as the server and client certificates.

That's the issue. I only checked my CA certificate; the server has an MD5 certificate.

And regarding ...

You're joking, right? I should redeploy the entire VPN because of this bug?

If you are using MD5 certificates, you should definitely do exactly that. More details can be found in these few tweets from the @OpenVPN account: https://twitter.com/OpenVPN/status/899604229240877056

That depends entirely on why one is using a VPN. I don't give a hoot about encryption quality, and very little about the risk of strangers joining my VPN. For me it's all about routing.

Nevertheless I'll probably upgrade over the holidays when I have access to all the machines involved.

There is a beta release on PlayStore (1.1.24 build 93) that is expected to support MD5 again. Would you mind giving it a shot and let us know if that works?

[YUChoe]

1.1.24 works again for me. Thanks! Good job

[ordex]

Yeah, the beta release is out live. MD5 is supported again.
Please have a look at the changelog: in 6 months MD5 will be definitely dropped, thus this is the time to act and get rid of broken algorithms!

[gkuenning]

I always gotta love the "We know better than you, so we're going to force you to change even though we don't understand your use case" attitude.

Sigh.

I cannot being to count the number of perfectly acceptable applications and services that have stopped working for me because somebody thinks they should be my parent. Not to mention the number of hours I've wasted working around this nanny-ism.

It's one thing to say "We recommend really strongly that you do X, for very good reasons Y." I've often--in fact, nearly always--made configuration changes as a result of such suggestions. But it's quite another to say "You MUST do X because we lack the imagination to see that there are reasons where X is either unnecessary or downright inappropriate."

[T84a]

Just to clarify one important detail, as I'm not sure if there is a confusion or not.

- Auth digest: SHA1

This line does NOT mean the certificate is not signed using an MD5 based signature.

Please check the output of:

Code: Select all

    $ openssl x509 -in $CERTIFICATE_FILE -noout -text | grep "Signature Algorithm"

Make sure you check the CA certificate, as well as the server and client certificates.

And regarding ...

You're joking, right? I should redeploy the entire VPN because of this bug?

If you are using MD5 certificates, you should definitely do exactly that. More details can be found in these few tweets from the @OpenVPN account: https://twitter.com/OpenVPN/status/899604229240877056

dazo,

I need help. Can you help me?