Upgrade to OpenVPN 1.2.5 (iOS): issues

[taiwanmobileservices]

Hi! Dazo,

Thanks for all the efforts to fix and details on the background.

As said many times, please make OpenVPN Connect App as Paid one with reasonable price for average end users and higher for enterprise/cooperates to collect some money to allow your ream to hire more skilled resources/development tools/ softwares ....

Just like you said Apple limits the development time for OpenVPN Connect App and other restrictions.

Thus, you guys should need such resources to rectify and solve the problem and even provide more features in the future versions.

As you may know there is some quite good OpenVPN Apps developed by third parties on the Android market like OpenVPN App and VPN Client Pro, which provides more features such as obfs2/3/4 and both are Paid version ....

OpenVPN is one of the third party VPN protocols allowed in the closed iOS environment.

So, you will get our support for such small money payment to buy and enjoy your OpenVPN Connect App.

FYI, the pure OpenVPN is not even working in China, where the people is using ShadowsocksR these days!

Do not make it free and short of resources to make it more powerful!

Thanks/Br,

Birdman Hsu

Just to explain a bit further on a few details

Regarding retracting the 1.2.5 release and have 1.1.1 in the appstore again. Apple gave OpenVPN Inc a hard deadline on the old VPN API. Any app updates to OpenVPN Connect after July 2017 cannot utilize the old VPN API. This is out of our control. So we are forced by Apple to move forward. To rollback or even re-release the old 1.1.1 with a newer version number will be blocked by the Appstore before it reaches all the users - due to the fact that the app will then use an API which is no longer approved.

Regarding the issues related to the keychain. The newer VPN API we needed to move towards to is far more stringent and stricter in the access control. The old API was much more open and forgiving, and it was possible to access keying material outside the "domain" of the single app. This power is bad for device security. So when we now do not have that access, it is definitely seen as a user experience regression. But again, this is also outside our control. Apple enforces OpenVPN Connect updates to use the newer VPN API, and we need to play within the boundaries that gives us. One way to circumvent all this is to have the key/cert/ca files embedded into the configuration file.

Some users have utilized --tls-auth without using --key-direction (either explicitly or indirectly via the --tls-auth option as the last argument). That this worked initially has actually been a bug, and it degrades the overall security layer --tls-auth can provide. Those who switched to --tls-crypt will not see these issues, as --key-direction is automatically handled correctly. That said, --tls-crypt gives an even stronger protection than --tls-auth would provide; so this move alone is a good improvement.

There are probably a few more other issues which would deserve comments too ... but currently, these three areas have been taking most of the focus of the discussion in this thread.

All that said ... We are working on a new release, which is just about to hit testing and QA ... it seeks to remedy a lot of the issues reported. We've focused on the critical ones first for this first update. And some other issues may need to in a later release, as they need more work and we don't want to hold back a release for issues where we have fixes ready.

Despite many of you have had a bad experience with this update, we also have a lot of users telling us this update improved their situation - where it now finally works better in their environments. So this update broke some configurations while other configurations got improved. With that in mind we cannot conclude that this update was ultimately an utter and complete disaster. But it also wasn't a complete successful story either, unfortunately.

And finally, all the feedback has been valuable - in various degrees. But some post have been less constructive and useful. We fully understand and sympathize with the frustration when something truly and badly breaks - especially if your responsible for many users. But please be considerate in the wording you use when responding and raising awareness about issues. What I'm about to write, is truly sad and disturbing to write. But it seems needed. Personal attacks, questioning processes or competences or other derailing of the discussion thread is not much valuable and it belongs nowhere in these discussion threads. Most of you have have behaved well, and we could have a constructive dialogue. But some posters have experienced or will experience their posts being removed or even banned. This is not because we want to censor the forum, but simply because it provides nothing to the discussion at all. Remember that behind each and single post, there is a living human being. When submitting a post, think through how you would experience the message you're about to submit if you were the receiver and not the sender. So be considerate and respectful, and you will experience we take your feedback serious.

Thank you all ... now at least I need to get back to work

[anatoli]

Some users have utilized --tls-auth without using --key-direction (either explicitly or indirectly via the --tls-auth option as the last argument). That this worked initially has actually been a bug, and it degrades the overall security layer --tls-auth can provide.

The documentation for both 2.3 and 2.4 states otherwise:

Code: Select all

--tls-auth file [direction]
See the --secret option for more information on the ***optional*** direction parameter.

Code: Select all

--secret file [direction]
Enable Static Key encryption mode (non-TLS). Use pre-shared secret file which was generated with --genkey.

The ***optional*** direction parameter enables the use of 4 distinct keys (HMAC-send, cipher-encrypt, HMAC-receive, cipher-decrypt), so that each data flow direction has a different set of HMAC and cipher keys. This has a number of desirable security properties including eliminating certain kinds of DoS and message replay attacks.

When the direction parameter ***is omitted***, 2 keys are used bidirectionally, one for HMAC and the other for encryption/decryption.

The direction option was always and still is an optional param.

[ordex]

Some users have utilized --tls-auth without using --key-direction (either explicitly or indirectly via the --tls-auth option as the last argument). That this worked initially has actually been a bug, and it degrades the overall security layer --tls-auth can provide.

The documentation for both 2.3 and 2.4 states otherwise:

Code: Select all

--tls-auth file [direction]
See the --secret option for more information on the ***optional*** direction parameter.

Code: Select all

--secret file [direction]
Enable Static Key encryption mode (non-TLS). Use pre-shared secret file which was generated with --genkey.

The ***optional*** direction parameter enables the use of 4 distinct keys (HMAC-send, cipher-encrypt, HMAC-receive, cipher-decrypt), so that each data flow direction has a different set of HMAC and cipher keys. This has a number of desirable security properties including eliminating certain kinds of DoS and message replay attacks.

When the direction parameter ***is omitted***, 2 keys are used bidirectionally, one for HMAC and the other for encryption/decryption.

The direction option was always and still is an optional param.

I can't speak directly for dazo, but I think he meant that allowing the user to have "bidirectional" mode was a bug in the *design* of tls-auth, because it slightly degrades its security (still not enough to break it) without any real benefit (maybe configuration simplicity?).
For this reason such mode does not exist in tls-crypt (it decides the direction autonomously without the need of an additional param).

[Matteo13]

Hello, this release is working fine for me, just a minor issue with "tls-crypt".

According to the man page, "tls-crypt" does not require "key-direction" set on both ends so I edited the server config like this:

Code: Select all

tls-crypt /etc/openvpn/tls.key

Then in the client config I removed:

Code: Select all

key-direction 1

And turned the inline key from

Code: Select all

<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>

to

Code: Select all

<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-crypt>

However the server log still reports this warning on connection:

Code: Select all

WARNING: 'keydir' is present in remote config but missing in local config, remote='keydir 1'

In fact the client (on version 1.2.5) still announces inside "Tunnel Options:" keydir 1

[ordex]

However the server log still reports this warning on connection:

Code: Select all

WARNING: 'keydir' is present in remote config but missing in local config, remote='keydir 1'

In fact the client (on version 1.2.5) still announces inside "Tunnel Options:" keydir 1

Thanks for the report. Your config changes are correct.

Am I right saying that the connection still works as expected? This is probably just a cosmetic issue - keydir should not be sent in the option string.

[Matteo13]

Thanks for the report. Your config changes are correct.

Am I right saying that the connection still works as expected? This is probably just a cosmetic issue - keydir should not be sent in the option string.

Ok so it's not a security issue? I assume the string is ignored by the server.

By the way, aside from this the connection works as expected.

[ordex]

Thanks for the report. Your config changes are correct.

Am I right saying that the connection still works as expected? This is probably just a cosmetic issue - keydir should not be sent in the option string.

Ok so it's not a security issue? I assume the string is ignored by the server.

no, it is not. server and client simply exchange their set of options to see if something is mismatching and warn the user (like in this case, but it's a false positive).

By the way, aside from this the connection works as expected.

perfect! Thanks for letting us know.

[Matteo13]

Ok got it, thanks for the prompt replies.

[dazo]

Just a quick feedback to this suggestion.

Hi! Dazo,

Thanks for all the efforts to fix and details on the background.

As said many times, please make OpenVPN Connect App as Paid one with reasonable price for average end users and higher for enterprise/cooperates to collect some money to allow your ream to hire more skilled resources/development tools/ softwares ....

It is truly great that we have users willing to pay for the OpenVPN Connect app. We certainly can consider this for the future, but this is not the only way we can get more funding.

Regardless, the current situation now will not be resolved by adding more man power. That step has already been taken long ago and there are a lot of on-going development as we speak on the next generation client and services. So right now have full focus on fixing the current issues, as these current issues would also hit the next generation products as well.

And I do want to emphasize yet more that the current issues, which truly hits hard on those users having problems now, are still quite few compared to the rest of the user base. But when you have the amount of downloads OpenVPN Connect has, even if just 5 or 10% of the user base experience issues, it affects very many individuals. And for each of these individuals, the current situation is bad - we have deep respect for that.

We have already started testing the next version of the OpenVPN Connect iOS app. So when we're satisfied with the test results and are confident the issues we try to fix are resolved, it will be published instantly.

[dazo]

Some users have utilized --tls-auth without using --key-direction (either explicitly or indirectly via the --tls-auth option as the last argument). That this worked initially has actually been a bug, and it degrades the overall security layer --tls-auth can provide.

The documentation for both 2.3 and 2.4 states otherwise:

Code: Select all

--tls-auth file [direction]
See the --secret option for more information on the ***optional*** direction parameter.

Code: Select all

--secret file [direction]
Enable Static Key encryption mode (non-TLS). Use pre-shared secret file which was generated with --genkey.

The ***optional*** direction parameter enables the use of 4 distinct keys (HMAC-send, cipher-encrypt, HMAC-receive, cipher-decrypt), so that each data flow direction has a different set of HMAC and cipher keys. This has a number of desirable security properties including eliminating certain kinds of DoS and message replay attacks.

When the direction parameter ***is omitted***, 2 keys are used bidirectionally, one for HMAC and the other for encryption/decryption.

The direction option was always and still is an optional param.

I can't speak directly for dazo, but I think he meant that allowing the user to have "bidirectional" mode was a bug in the *design* of tls-auth, because it slightly degrades its security (still not enough to break it) without any real benefit (maybe configuration simplicity?).

This is correct. I'm sorry I wasn't clear about the design aspect. This need to be further discussed in the developers community, to see how we can improve this.

That said, I probably wouldn't say that it slightly degrades the security. If you manage to bruteforce the tls-auth key, you have can inject packets in both to client and server. If using --key-direction properly, two keys needs to be retrieved before getting the same result. Whether an attacker just needs the key for a single direction or both directions, is of course unknown - as it depends on the goal for the attack. If it just wants to attack the server and not be in a MITM position, only the key the server side uses for verification needs to be retrieved.

But this is now de-railing the current discussion thread, so I'll stop now

[taiwanmobileservices]

Hi! Dazo,

Thanks again for the great effort for doing the fix now.

Once rectify these major outstanding issues, hope you guys can make some IAP or with new paid App name like OpenVPN Connect Plus App.

I am willing to buy it;-)

Thanks/Br,

Birdman Hsu







one

Just a quick feedback to this suggestion.

Hi! Dazo,

Thanks for all the efforts to fix and details on the background.

As said many times, please make OpenVPN Connect App as Paid one with reasonable price for average end users and higher for enterprise/cooperates to collect some money to allow your ream to hire more skilled resources/development tools/ softwares ....

It is truly great that we have users willing to pay for the OpenVPN Connect app. We certainly can consider this for the future, but this is not the only way we can get more funding.

Regardless, the current situation now will not be resolved by adding more man power. That step has already been taken long ago and there are a lot of on-going development as we speak on the next generation client and services. So right now have full focus on fixing the current issues, as these current issues would also hit the next generation products as well.

And I do want to emphasize yet more that the current issues, which truly hits hard on those users having problems now, are still quite few compared to the rest of the user base. But when you have the amount of downloads OpenVPN Connect has, even if just 5 or 10% of the user base experience issues, it affects very many individuals. And for each of these individuals, the current situation is bad - we have deep respect for that.

We have already started testing the next version of the OpenVPN Connect iOS app. So when we're satisfied with the test results and are confident the issues we try to fix are resolved, it will be published instantly.

[danielbright]

Has it worked for you? Can you send it to me? (danquel@hotmail.com) thank you, we are desperate

The above method does work (FYI I rolled back my openvpn app to v1.1.1) but you need to follow the above youtube tutorial by yourself. I cannot share my ipa file with you as the app is tied to my iTunes account.

I also can confirm that. It's working. Just rolled back to v1.1.1.

I followed the youtube link and the following tutorial: https://medium.com/@iosight/how-to-lega ... 45559b8357

The correct string for the version 1.1.1 is:

Code: Select all

819500456

With this information you can follow the tutorial from step 15. All steps above are only to find out the right string.

Of course you need the right iTunes version mentioned above to enter the app store and fiddler installed.

Thank you very much for this! It actually worked. I've learned my lesson to never update a critical application again without waiting for a few days and reading the community response first.

To the developers; We had multiple issues (some already reported in this thread) but also an issue where the connection was simply interrupted in the middle of a session. Reconnecting would result in another working session for about 10-60 seconds followed by a disconnect again. Nothing out of the ordinary in the logs. Except for the latest release thank you for a great application!

[daniel1113]

Upgrading to 1.2.5 has killed local DNS resolution. OpenVPN connects to the server and sets the local DNS servers and search domain. However, iOS is unable to resolve any local IP addresses.

This all worked fine on 1.2.4 and earlier versions. DNS resolution still works fine in 1.1.1 which I have running on another iOS device, as well as using Tunnelblick on macOS. Will this be fixed in 1.2.6?

This looks like a confirmed problem with 1.2.5 per viewtopic.php?f=36&t=25598

[ordex]

This looks like a confirmed problem with 1.2.5 per viewtopic.php?f=36&t=25598

You are right. This will be fixes in 1.2.6. Beta testers have already confirmed it being fixed.

[Nuno18]

Hello!

The only way to generate an Apple mobile configuration file with the settings of an openvpn file is only through a Mac computer?

[ordex]

Hello!

The only way to generate an Apple mobile configuration file with the settings of an openvpn file is only through a Mac computer?

the .mobileconfig file is just an xml-like text file. If you know the format you can write it with your favourite text editor.

mod: Please, let's stop hijacking this thread with all kind of random questions and let's open new appropriate threads.

[iPhrankie]

I know no one likes ETA questions, but is there any update on when a new iOS app will get published? Sometime this week?

Thanks for all the work you guys are doing!

[Alexandr1047]

I have a problem after customers who use the application on ios. It all started after the upgrade to the new version. On other devices, everything is in order. The problem is that the client can connect to the server, but after 5 minutes of work (for example, browsing the web), the connection is lost and there is no restart. I have to manually restart the application. I ask your help in solving this situation. Maybe someone has come across this.

[ordex]

We have fixed several connectivity issue, therefore I'd wait for the new release and then re-test to see if it's fixed.

To answer the other users: we are currently going through the final Apple review, therefore we expect a new release anytime this week.

[Nuno18]

Hello,

The problem that existed since version 1.1.1 and that remained in 1.2.5 of the VPN connection when it was active through the mobile network if it is constantly reconnecting with differences of only a few seconds and that causes the battery to discharge itself much faster has it been resolved?