From dd6d365fb67ca992617e87a04ab61b17feffdecd Mon Sep 17 00:00:00 2001 From: Arne Schwabe Date: Tue, 29 Sep 2020 12:21:24 +0200 Subject: Fix typo in the word proprietary Noticed by random dragon on reddit. --- main/src/main/res/values/strings.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'main') diff --git a/main/src/main/res/values/strings.xml b/main/src/main/res/values/strings.xml index 20814297..4aa83ee9 100755 --- a/main/src/main/res/values/strings.xml +++ b/main/src/main/res/values/strings.xml @@ -499,6 +499,6 @@ Default VPN not set. Please set the Default VPN before enabling this option. Internal WebView Failed to negotiate cipher with server - 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 properitary 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). + 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). -- cgit v1.2.3