List or indicator of supported tls/ciphers/hashes

[Jruuu]

I request OpenVPN sort the --show-tls --show-ciphers --show-digests lists under two headings, "Supported" and "Not supported" i.e:

openvpn --show-tls

Available TLS Ciphers,
listed in order of preference:

Supported TLS-Ciphers:

TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-CBC-SHA

Not supported:

TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-DSS-WITH-AES-256-CBC-SHA
TLS-SRP-SHA-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-DSS-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-DSS-WITH-AES-256-CBC-SHA256

...or to add (supported) or (not supported) beside each value:

Available TLS Ciphers,
listed in order of preference:

TLS-DHE-RSA-WITH-AES-256-CBC-SHA (supported)
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 (not supported)

No documentation covers what is supported or not, which will give many users the false impression that they have errors with their configuration. I first thought all of the tls-ciphers in --show-tls were supported, because they were showing up in the list. I later found out my server and clients were properly configured, and that the tls-cipher (TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384) I had selected was not supported (after three hours trying to find a solution).

[MaxMuster]

As far as I understood, --show-XY will just list all the available ciphers.
Can you please provide some more and detailed information of your issue? There should be some more input (of your configuration) and some more "output" (logs of the failing connections).

In my tests the "show" parameters work like expected. (Of course, the tls-ciphers must be present on "both sides", server and client must support them).

But in my tests I found an issue as a result of the "translation" in the switch to IANA names for the TLS ciphers. The table has duplicate entries for some "TLS-XY" ciphers, I found these four

TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA
TLS-DHE-DSS-WITH-DES-CBC-SHA
TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
TLS-DHE-RSA-WITH-DES-CBC-SHA

So, translation in one direction (OpenSSL-Names to IANA) is fine, but when trying to find the "corresponding" entry for e.g. "TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA" an OpenSSL based binary will fail to start:

Mon Jul  8 22:52:50 2013 us=32250 Failed to set restricted TLS cipher list: DHE-RSA-DES-CBC3-SHA: error:1410D0B9:lib(20):func(269):reason(185)

This is clear, for the correct cipher is not DHE-RSA-DES-CBC3-SHA but EDH-RSA-DES-CBC3-SHA.

I did not find the "DHE-..." entries in OpenSSL (in openssl-1.0.1e or openssl-0.9.8r), only the "EDH-.." ones.
So, from my point of view, it was sufficient do delete the "DHE-" entries. If they are used for another version, one might use "defines" depending the SSL-library version to make sure, the translation table has unique entries.

[MaxMuster]

Patch to remove duplicete entries in SSL/TLS Cipher suite name translation table

[Steffan Karger]

The --show-tls should only show the ciphers supported by your local TLS library, but, as MaxMuster? already states, the libraries at both ends should support the cipher.

Furthermore an ACK for the patch by MaxMuster?. These four entries should not be present in the list and probably slipped in due to their exceptional EDH- prefix instead of the regular DHE-.

[Gert Döring]

So, there's two things.

1. the patch from Max has been committed (e85d87523af43c5fe5188f7ee1e2fdd2861dcffc in master, d976909438a8786b7f5b59088cf4966f90c5f928 in release/2.3) and pushed

2. there was a thread on openvpn-users under the heading " Can't connect using tls-cipher TLS-SRP-SHA-DSS-WITH-AES-256-CBC-SHA" - I think this is what the "not supported" is all about: OpenSSL can happily support that cipher, but since OpenVPN would have to supply different credentials(?) for SRP, it will still not work. I'm not sure if I understood the issue completely, but maybe you can, when reading the thread :-) - ​http://article.gmane.org/gmane.network.openvpn.user/34488.

-> back to syzzer, you understand crypto.

[jwm]

You seem to be missing the point: the manual page entry for --tls-cipher says: “Use --show-tls to see a list of supported TLS ciphers.” which most people would assume to mean, ‘supported by openvpn’.

In practice, this list includes SRP key exchange suites not supported by openvpn (nor ever likely to be) and GCM and SHA-2 based suites that have only recently been enabled in git master.

Couple that with --tls-cipher failing to filter out unsupported-by-openvpn suites (#358) and the rather poor TLS suite diagnostics (#359), and you can, as I've just done, waste several hours trying to configure SHA256 suites that can't be used :-/

[Steffan Karger]

I completely agree this is confusing behaviour and should be improved. To relieve the pain a bit I just submitted a patch to the mailinglist that explicitly disables the unsupported PSK and SRP cipher suite groups. That should at least clean up the --show-tls output a bit. ECDH support should get into master soon, so I did not disable that group yet.

The true problem is however that the combination of local and remote TLS libraries determine which cipher suites will work. That combination is not possible to determine when executing openvpn --show-tls locally.

Furthermore, I've not yet been able to find a way to ask OpenSSL to report the list of supported cipher suites given the initialisation (i.e, when I do not initialise DH, I would likt OpenSSL to not report DH-based ciphers), which makes it hard to really fix the issue at hand. If anyone is aware of a way to get this information from OpenSSL, please submit patches, or let me know how to do it. I'll be happy to get it into OpenVPN.

[IncreasedSecurity]

I would like to second this request in very strong terms, and add my thanks to syzzer for accepting Jruuu's ticket. I just spent several hours I didn't have to waste attempting to track down why my new VPN setup didn't work, ending up walking down a combinatorial list to attempt to find the most secure combination that actually worked by trial and error, with service restarts thrown in at every change because I had no idea why it wasn't working.

I would like to also suggest ordering --show-ciphers and --show-digests in order of preference as well, or at least separate the blatantly weak (ciphers: RC2-40-CBC, I'm looking at you right in the middle of the list on Windows) from the current top end of "not known to be vulnerable" (ciphers: AES and Camellia families, digests: SHA2 family, whirlpool).

syzzer: "The true problem is however that the combination of local and remote TLS libraries determine which cipher suites will work."

This can be made clear in a static comment in the output, something like "The list of supported <type> below is for this particular implementation; please check what values for <type> the other implementation(s) that will be connecting to this one allow, and choose one that is supported by all the implementations that will be connecting to the same VPN."

That said, I DID execute openvpn --show-digests, openvpn --show-ciphers, and openvpn --show-tls on every single instance that would be connecting to each other. I only chose combinations supported by all clients (OpenVPN for Android 0.6.11 doesn't support Camellia, as one example).

When I see OpenVPN tell me "Available TLS Ciphers, listed in order of preference:" I expect them to be available for use if all servers and clients involved show them, and I think this is a common understanding of "available" in the context given.

The only way I found of figuring it out was extensive trial and error. Only after the fact, once I finally figured out that not only was all ECDHE not working, but no GCM was working could I have easily found this ticket.

[Gert Döring]

Going through the list of open tickets - what is the state of things here? Is what we currently have and show "good enough" (or "as good as it can get, with OpenSSL") or can we improve things further?

In other words: document what we have and close this bug?

[Steffan Karger]

The warning/notice similar to what IncreasedSecurity? suggested above just went in:
​http://thread.gmane.org/gmane.network.openvpn.devel/9651/focus=9668

This, in combination with better error reporting (see #359), and the earlier patch to clean up the --show-tls output is what I think is reasonable to resolve in OpenVPN. Also consider the relatively new --tls-version-min, which is a way less error prone way to increase your minimum security level.

--tls-cipher really is an expert feature, and without adding high-maintenance code that relies on OpenSSL internals, I think this is as good as it gets.