Opened 7 years ago

Closed 6 years ago

#358 closed Bug / Defect (wontfix)

--tls-cipher will accept values openvpn cannot use

Reported by: jwm Owned by:
Priority: minor Milestone:
Component: Configuration Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger

Description

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

Change History (5)

comment:1 Changed 7 years ago by 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.

comment:2 Changed 7 years ago by JoshC

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

comment:3 Changed 7 years ago by 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?

comment:4 Changed 6 years ago by Gert Döring

Cc: Steffan Karger added

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?

comment:5 Changed 6 years ago by Steffan Karger

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.