diff options
| -rwxr-xr-x | main/src/main/res/values/strings.xml | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/main/src/main/res/values/strings.xml b/main/src/main/res/values/strings.xml index 70cca720..fe5a7a06 100755 --- a/main/src/main/res/values/strings.xml +++ b/main/src/main/res/values/strings.xml @@ -492,7 +492,7 @@ <string name="import_from_as">Import Profile from Remote Server</string> <string name="no_default_vpn_set">Default VPN not set. Please set the Default VPN before enabling this option.</string> <string name="internal_web_view">Internal WebView</string> - <string name="faq_ncp">There are some variation of this message depending on the exact situation. They all have in common that server and client could not agree on a common cipher. The main reasons are: <ul><li> You are still relying on the fact that OpenVPN 2.4 and older allowed BF-CBC in the default configuration (if no --cipher was set). OpenVPN 2.5 does not allow it per default anymore since it is a <a href="https://community.openvpn.net/openvpn/wiki/SWEET32">broken/outdated cipher</a>.</li><li>The server runs OpenVPN 2.3 (or even older) with --enable-small (at least 4-5 year old OpenVPN)</li><li>Broken configuration (e.g., mismatching data-ciphers on client and server)</li> <p> The <a href=\"https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst\">OpenVPN manual section on cipher negotiation</a> explains the different scenarios of cipher negotiation very well and what to do in these situation.<p>TP-Link devices use a at least 5 year old OpenVPN 2.3.x version (possibly older) on their devices, even in the 2019/2020 models.<p>Last but not least, there is a popular VPN provider that has a broken server that always says it is using \'BF-CBC\' because its developer thought it would be a good idea to create a proprietary cipher negotiation patch that is incompatible with standard OpenVPN.<p>In summary: all sane configurations should not get these errors. But (apart from the broken VPN provider\'s server) the client can be persuaded to still connect (fixing the sympton and not the real problem).</string> + <string name="faq_ncp">There are some variation of this message depending on the exact situation. They all have in common that server and client could not agree on a common cipher. The main reasons are: <ul><li> You are still relying on the fact that OpenVPN 2.4 and older allowed BF-CBC in the default configuration (if no --cipher was set). OpenVPN 2.5 does not allow it per default anymore since it is a <a href="https://community.openvpn.net/openvpn/wiki/SWEET32">broken/outdated cipher</a>.</li><li>The server runs OpenVPN 2.3 (or even older) with --enable-small (at least 4-5 year old OpenVPN)</li><li></ul>Broken configuration (e.g., mismatching data-ciphers on client and server)</li> <p> The <a href=\"https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst\">OpenVPN manual section on cipher negotiation</a> explains the different scenarios of cipher negotiation very well and what to do in these situation.<p>TP-Link devices use a at least 5 year old OpenVPN 2.3.x version (possibly older) on their devices, even in the 2019/2020 models.<p>Last but not least, there is a popular VPN provider that has a broken server that always says it is using \'BF-CBC\' because its developer thought it would be a good idea to create a proprietary cipher negotiation patch that is incompatible with standard OpenVPN.<p>In summary: all sane configurations should not get these errors. But (apart from the broken VPN provider\'s server) the client can be persuaded to still connect (fixing the sympton and not the real problem). When connecting to older servers the comaptiblity mode option in the basic settings of a VPN should be able to address most of the common compatiblity problems.</string> <string name="check_peer_fingerprint">Check peer certificate fingerprint</string> <string name="fingerprint">(Enter the SHA256 fingerprint of the server certificate(s))</string> <string name="proxy_info">HTTP Proxy: %1$s %2$d</string> |