--tls-cipher will accept values openvpn cannot use

[jwm]

Openvpn will allow the settings of --tls-cipher values that are supported by the underlying cipher library (ie openssl), but are not actually supported by openvpn itself, such as SRP key exchange suites, TLS1.2 suites (which include all GCM modes and SHA-2 digests).

This problem is exacerbated by --show-tls reporting unsupported ciphers, and this hardening documentation incorrectly stating that SHA-2 bases suites are supported: ​https://community.openvpn.net/openvpn/wiki/Hardening

[JoshC]

This is mostly correct, although do note that TLSv1.2 is supported in git-master as stated on the linked wiki; this includes SHA2 and GCM modes. <=2.3.2 (the latest official release) does not have commit 4b67f98 and thus won't work. In addition to the -master branch, a future 2.3.3 release is likely to have this support.

The issue gets a bit more complex when you consider that future support of EC vs RSA crypto will be dependent on the runtime configuration; ECDHE cipher-suites would of course be worthless if the keys used are RSA, but fine otherwise.

Basically, --show-tls is giving you the options the TLS library supports, not necessarily "everything you're allowed to use with openvpn in any configuration." At some point the person writing the configs has to be aware of the differences in RSA vs EC, TLS 1.0 vs 1.2, and DHE vs DH.

All this said, modes like SRP or PSK that aren't used are effectively worthless. I'm not sure what the code changes would require to remove at least these modes. There is some movement to remove the "export" ciphers from the list currently, so perhaps this can be evaluated as well.

[JoshC]

Just a quick note that the wiki page did incorrectly put SHA256 variants under the TLSv1.0 section. This has now been corrected.

[jwm]

Ok, first up, --show-tls should only report the subset of cipher suites that openvpn can use. I can run eg openssl ciphers -v if I want to know what the underlying library can support. That's what #304 is about, and it would have saved me much pain.

The --tls-cipher behaviour for handling unsupported ciphers can be the same as it is for untranslatable cipher names: drop them at initialization time with a log message. I'd add a final log message with the final working list, too. Bonus points for adding a reason, ie unsupported versus insufficient configuration. If the final list is empty, that should be a fatal error.

As far as handling old ciphers goes, won't it make sense to use the !+- syntax that openssl uses, and just set some sort of sensible default?

[Gert Döring]

Since quite a bit of work went into --show-ciphers and such in the 2.3 series - is this still relevant, or has it been addressed in the course of #304?

[Steffan Karger]

We did improve the --show-tls output, and 'no shared cipher' error reporting. However, implementing and maintaining decent checking of --tls-cipher is not worth the trouble imho.

--tls-cipher really is an expert feature. Users who want painless extra 'security assurances' should use --tls-version-min and --tls-auth.

(Note that unlike browsers, OpenVPN does not perform a 'downgrade dance', making it a lot saner to rely on the SSL libary's own version/cipher downgrade protection. Especially in combination with --tls-auth.)

I'm closing this ticket as 'wontfix' for now, as I believe the extra measures already in place reduce the pain sufficiently, and any more effort is simply not worth the trouble.