“ncp-disable” option entirely broken

[bruceleerabbit]

General information

1. Android Version 5.1.1
2. Android Vendor/Custom ROM stock
3. Device obscure
4. Version of the app (version number/play store version/self-built) f-droid/0.7.41

Description of the issue

Imported a configuration file that included the ncp-disable option. The GUI defaults “TLS Security Profile” to legacy (default). Since no crypto is needed (hence the ncp-disable option), I overrode TLS sec. prof. with insecure. The GUI should have noticed the ncp-disable & should have defaulted to insecure in that case.

The GUI also defaults to ticking a box “Import PKCS12 from configuration into Android Keystore”. Again because ncp-disable is specified, that box should be unticked automatically. I manually unticked it.

The GUI demands a key even when the user explicitly directs the app to not use encryption.

After importing, an error is displayed below the new profile: “You must select a User certificate, legacy Pro”. Not sure what the trailing “legacy Pro” is about, but this error is unexpected for an in-the-clear config. In the basic tab, I had to untick “Load OpenSSL legacy provider” because that’s irrelevant to an unencrypted configuration. There is also a Type pulldown which defaults to Android Certificate. That must change because it leads to the instant error msg on the profile. But none of the other options are appropriate for an unencrypted configuration. I chose external auth provider figuring it would be the least demanding of irrelevent info.

bug #1419 may be related.

Log (if applicable)

KeyChain Access error: Alias or external auth provider name not set.
Cannot access the Android Keychain Certificates.…

Configuration file

# Enables connection to GUI
management /data/data/de.blinkt.openvpn/cache/mgmtsocket unix
management-client
management-query-passwords
management-hold
machine-readable-output
verb 4
connect-retry-max 5
connect-retry 5 300
#resolv-retry 60
dev tun
remote 192.168.42.128 13444 tcp-client
comp-lzo
ifconfig 192.168.7.29 192.168.7.28
route 0.0.0.0 0.0.0.0 vpn_gateway
dhcp-option DNS 8.8.4.4
dhcp-option DNS 8.8.4.4
dhcp-option DOMAIN blinkt.de
nobind
persist-tun
#persist-tun also enables pre resolving to avoid DNS resolve problem
# Use system proxy setting
management-query-proxy
mute-replay-warnings
resolv-retry infinite
keepalive 10 60
ping-timer-rem
ncp-disable

[schwabe]

ncp-disable was a debug option to diagnose ncp problems. The options has been removed now.

ncp-disable has nothing to do with all the other option that you are writing about. You have a massive misunderstanding what the option actually did.

It seems like you trying to use a p2p openvpn config without any crypto. My app does not really allow you to configure that.

[bruceleerabbit]

It seems like you trying to use a p2p openvpn config without any crypto. My app does not really allow you to configure that.

Indeed I also added these options:

auth none
cipher none

and same problem. Is there an expectation that the openvpn app be 100% compatible the desktop app? I think users naturally expect this, so “Limitations and known interoperability bugs” should ideally be documented somewhere.

[schwabe]

This kind of config is extremely rare that I never came around adding proper support/fixes for it. It isi just a so rare corner case that it is extremely low on the priority list and will probably also removed in the future from OpenVPN.

[bruceleerabbit]

This kind of config is extremely rare that I never came around adding proper support/fixes for it. It isi just a so rare corner case that it is extremely low on the priority list and will probably also removed in the future from OpenVPN.

Three use-cases come to mind:

1. Running over a LAN or USB cable (e.g. for reverse-tethering).
2. Running a tunnel within another tunnel, where the exterior tunnel provides sufficient confidentiality and the inner tunnel is just used to create a separate namespace (perhaps for experimental purposes, or perhaps a user is forced to use one kind of tunnel like SSH to conceal another variety of tunnel).
3. Testing & troubleshooting.

Use-case 3 is important enough for development and troubleshooting (both by users and devs) that in-the-clear sessions will unlikely ever be depricated. The reason I attempted to disable crypto was a consequence of a real-world scenario: blowfish was being rejected sometimes, and sometimes not, without pattern, & it wasn’t even needed for the task at hand anyway (use case 1). Even if it were needed, it's still useful to divide & conquer — to fix each problem in isolation one at a time with the simplest configuration.

Use-case 1 should be a lot more popular than it is. I think it’s a matter of time before the general public becomes aware of all the privacy abuses inherent in the huge attack surface that wi-fi brings, in light of iOS and non-hardened AOS devices feeding all to Google Inc.

There’s also an ecological CO₂ component to use-case 1, whereby wifi radios generate waste heat next to batteries, which consume more energy to power the radio & while the heat also lessens the charging efficiency. All that radio energy waste, ineffecient charging as well as the energy waste of needless encryption-decryption can be spared with use-case 1 w/out crypto. I also suspect batteries have a longer lifetime in that scenario too, which also has an ecological benefit.

[schwabe]

@bruceleerabbit We plan to remove the whole non-TLS mode in OpenVPN eventually since it is not used very much but requires a lot of maintanance. The reality is just that it is not really used and not the focus of OpenVPN.