Poor reporting of no shared ciphers.

[jwm]

If a pair of openvpn instances cannot find a shared cipher (for instance, because of a short or misconfigured --tls-cipher directive), the error is poorly reported. ie for a client/server configuration, with --tls-cipher used on the server side, the server side, at verb 2, reports:

TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL routines:SSL3
_GET_CLIENT_HELLO:no shared cipher

While the client side reports cryptic errors.

Ideally, 'No shared TLS cipher' should be reported at verb 1, while the ciphers supplied by both ends during negotiation should be displayed at a higher verbosity level.

This problem is exacerbated by --tls-show supplying unsupported ciphers (#304) and --tls-cipher accepting ciphers unsupported by openvpn (#358).

[Steffan Karger]

I agree this can be improved. In response to this ticket I sent a patch to the list a while ago, which was committed to git a little while ago:
​https://github.com/OpenVPN/openvpn/commit/c3e1809

This adds a more clear, verb 1, error message about the failure to find a shared cipher, and gives the user a hint at where to look. Showing the actual supported ciphers for a specific configuration turned out to be not possible with openssl (without ugly, hard to maintain, hacks).

This patch is in the master branch only, because it needed some more intrusive rewriting of error reporting code, and more intrusive changes no longer go into release/2.3.

I'm closing this ticket, I hope you agree this is an acceptable compromise.