Adding a note on OpenVPN's tls-version-min option. #91
Conversation
In addition to the IANA compatible CipherSuite names which, when not being used, causes v2.3.1 to present deprecation warnings to the user, the list of Ciphers can also be narrowed down using the tls-version-min option on server side. It selects the minimum Version of the TLS protocol being used, as the name says. We might whant to give recommendations for IANA compatible names in another TL;DR copy list for now, since current operating systems already offer v2.3.6.
|
What are ppl's opinions on either delivering a TL;DR copy table of IANA compatible names ADDITIONALLY or REPLACING it completely since 2.3.1 was already published in march of 2013? |
|
I'd vote yes for that addition (except for the ending-spaces :) . Thanks! |
|
Why link and not put another list in there? Because at least for me this is the whole point of the document: TL;DR copy paste into config files. As to be seen here:
TLS 1.0 + OpenVPN <= v2.3.1:
TLS 1.0 respectively OpenVPN <= v2.3.2:
TLS 1.2 (requires all peers having OpenVPN >= v2.3.3):
Maybe we can just write a short notice about the TLS / OpenVPN Version constraints resulting in the cipherlists and throw in the two lists? :) |
historical note on cipherstring/suite naming: |
Really? From a quick search, I did not find any reason why CBC was bad in OpenVPN. Can you provide a source? (Not because I am doubting you, but because I am interested in what the Problem with CBC in OpenVPN is) |
|
@malexmave POODLE, et cetera. |
|
As I understand it, Poodle is an Issue in the SSLv3 implementation of CBC, which allowed Side-Channel attacks, and not in CBC itself. Current version of OpenVPN are using TLSv1.* and should not be vulnerable, unless I misunderstood something. So, wouldn't it be sufficient to disable SSLv3 for OpenVPN (where it is still available, as the current version has it disabled by default, according to this discussion)? Or am I missing something completely obvious here? |
|
I can't speak of OpenVPN in practice (have been using IPSec the last years) - so it's good to know that OpenVPN doesn't support v3 anymore. Still the Lucky13 attack does apply. Basically as Adam Langley mentions in his blog: everything below TLS 1.2 using AEAD is broken. |
|
I'm not a crypto expert by any means, so please let me know if I'm wrong here, but wasn't that fixed in all relevant implementations? The info page for Lucky13 contains a list of "Patches, advisories and press", where it lists all major implementations as having released a patch. If I don't misunderstand you, that would mean that these modes are secure as long as you are using a recent version of your SSL library, and disabling these modes would only be necessary if you aren't (in which case: why not? That seems like a terrible idea). So, unless I misunderstand, wouldn't it be better to leave them on in the configuration and insert a note stating "if you are running an SSL/TLS implementation that is vulnerable to Lucky13 (OpenSSL <1.0.1d, ...), upgrade your implementation or disable CBC ciphers"? It just seems a tad bit excessive to disable a whole mode of operation due to a (to my knowledge) mostly fixed security issue. |
|
Yes I know, but these are implementation specific 'hacks' it's still a protocol flaw. CBC mode will be entirely removed in TLS 1.3, our recommendations pretty much try to not use CBC mode at all. Is it possible to do a current OpenVPN config. without CBC mode? If so then I'd really prefer it if we could go that way. |
|
Okay, so it's not so much that they are broken in the sense of "people can decrypt your stuff", and more of a "the protocol(s) contain a design flaw that we'd rather avoid, although there are no known attacks on it right now". I can understand your point now, thanks for the explanation. |
|
Yes. There are BTW. POODLE attacks on TLS as well (due to implementation errors), Adam Langley explains this in detail over here (it's a good read): https://www.imperialviolet.org/2014/12/08/poodleagain.html |
|
So basically a server requiring / running TLS 1.0 with an OpenVPN <= v2.3.2 and OpenSSL <1.0.1d (respectively having to deal with a client running the mentioned software stack) cannot be given any sense making recommendation? |
|
Exactly. That's not the fault of OpenVPN though. They use TLS tunneling instead of IPSec so they're prone to TLS protocol and implementation flaws on which they rely (but it's far better than designing your own crypto/tunneling stack or using L2TP!). TLS 1.0 is basically SSLv3 with a couple of minor changes. So regard TLS 1.0 (and 1.1 - which was the first real major protocol change since SSLv2->v3) as obsolete from a security point of view. These problems are also the reason why I haven't been using OpenVPN (or any TLS based VPN for that matter) in the last couple of years, and have recommended not to use those to my customers. FYI: Cisco ASA appliances and their AnyConnect product often use TLS (not 1.2!) instead of IPSec if it hasn't been especially configured for that. The same holds true for other VPN/Firewall/Networking vendors. Beware of marketing bullshit. |
|
So. With what you're saying, shouldn't the paper then recommend using TLS 1.2 / OVPN >= v2.3.3? Fine. But where to go from here? Since some netmins might have to use it, there should be a list of ciphers recommended... |
|
No I agree. Use TLS 1.2 with OpenVPN and a sound ciphersuite. This is what we use (OpenSSL syntax) for other services: https://git.bettercrypto.org/ach-master.git/blob/HEAD:/src/common/cipherStringB.tex Can you come up with a conforming ciphersuite that works with OpenVPN? Thanks, |
|
Well.
DES-CFB 64 bit default key (fixed) (TLS client/server mode) (Interesting. IANA in the streets, non-IANA in the sheets...) Since you define and therefore tell the server which ciphers to use explicitly, I think we can skip the negated ones. |
|
Hmmmm. Why isn't AES-GCM in their list? Any ideas? |
|
@ignisf Thanks for the reference. This should be merged ASAP. Someone willing to write to their bugtracker again? As long as there are no AEAD modes in there I think we cannot properly support OpenVPN per our recommendations. We can using legacy CBC mode, but this isn't really secure nor a good recommendation. @aaronkaplan what's your thoughts on that? |
|
Closing for reasons listed above & missing review by third parties. |
|
Hi, Let me introduce. I'm one of the OpenVPN developers and I just got a pointer to this discussion. I see some valid concerns being expressed here, but I think there are some misunderstandings too. 'Modern' OpenVPN (2.x, using the TLS mode) basically sets up two connections:
The list of ciphers posted by @doertedev above is a cipher list for the data channel, not the control channel. To see the list of TLS cipher reported as supported by the TLS library in use, use The OpenVPN data channel uses the Encrypt-then-MAC scheme (unlike TLS). I agree that CBC as used in TLS is fundamentally broken, but that is more the result of using MAC-then-Encrypt than of using CBC. CBC in combination with Encrypt-then-MAC is not broken. The compression mentioned above is specific to the data channel, so not to TLS. OpenVPN will even forcefully disable TLS compression all together in the upcoming release (see OpenVPN/openvpn@5b46cf4). Also note that even with TLS compression, it is not clear at all that the compression-based attacks on TLS will work for OpenVPN. Unlike browsers (which are RCE machines by design), the data passed over the OpenVPN control channel is very limited (both in amount and type of information) and not at all easy to control for an attacker. The OpenVPN control channel has long (untill 2.3.3) been fixed at TLS 1.0, but it has never even supported SSLv3. Since 2.3.3, it is possible to enable TLS 1.1 and TLS 1.2 by setting (Note that the above applies to OpenVPN builds using OpenSSL as a crypto library only. OpenVPN with PolarSSL does enable 1.1 and 1.2 by default.) In conclusion, I think OpenVPN is not fundamentally insecure. I do agree that some defaults need to be improved, but I also think that we should do that in a way that will not break our users setups. That makes it harder and slower. So in the mean time I really welcome any decent guidelines on hardening openvpn configurations. (PS I hope I didn't miss anything. If so, please let me know and I'll try to elaborate.) Edit: I tagged wrong user wrt cipher list, sorry. Fixed now. |
|
Thanks for clearing this up and giving some insight into how OpenVPN handles encrypted data connections. I agree that CBC in ETM mode is reasonable. But then again, why not support AEAD in the first place, especially since GCM has hardware support these days? Also is there an option to pass a TLS specific cipherstring for OpenVPN to use in the control channel? How do you know that attacks like CRIME cannot be performed on the OpenVPN data channel when it's using compression? To the best of my knowledge this is currently an open issue in cryptography (compression & encryption in general). edit: reopened issue. |
|
OpenVPN 2.4 will support AEAD modes, also for the data channel. The AEAD wire protocol will have some more improvements, such as less overhead and authenticating the opcode (data/control channel indicator) of packets too. The down side is that this slowed down development. At this point, we have agreement on the final spec, and implementations are progressing towards a stable state. TLS cipher suites can be controlled using the I agree that compression & encryption in general is risky. In the end it all boils down to whether an attacker can manage to get data of his choosing next to a secret of interest. For the control channel, I argue that an attacker who does not already controls one of the peers can not control the data in the control channel, and thus can not mount the typical compression attack. For the data channel controllling data next to a secret is only possible if some protocol going over the VPN link allows that. OpenVPN uses per-packet compression, so this must happen within the same packet. All this makes it harder (but not impossible) to mount an attack. I can image cases where a vpn admin considers this the responsibility of underlying protocols, but I can also imagine situations where that is not the case. OpenVPN has data channel compression disabled by default, and I think a hardening guideline should advise to leave compression disabled. |
|
@syzzer |
|
@dicer: yes, I'm talking about 'comp-lzo' (or 'compress' in the upcoming openvpn 2.4+). Just to be perfectly clear: I don't believe a setup is broken when compression is enabled. But to be completely sure compression can not be used to mount an attack, I'd recommend to leave it disabled unless you are sure there is no harm in enabling compression for your use case. |
|
closing this for now. feel free to comment. |
|
Hello, Is it better to disable compression even if we force TLS 1.2 ? |
|
Why and where do you think we should re-enable compression? In the TLS case: compression still is a vector for oracle attacks, e.g. CRIME or BREACH. I'm not too sure about the OpenVPN data channel either and would leave compression off in any case. |
|
I thought maybe it was related to the old SSLv3 compression flaw. ^^ |
|
Which SSLv3 compression flaw do you mean? Thanks, |
|
@azet I can't find it anymore, sorry 😢 |
|
I'm not aware of SSLv3 specific compression vulnerabilities. They are (for now) not restricted to a certain iteration of the protocol. |
In addition to the IANA compatible CipherSuite names which, when not
being used, causes v2.3.1 to present deprecation warnings to the user,
the list of Ciphers can also be narrowed down using the tls-version-min
option on server side. It selects the minimum Version of the TLS
protocol being used, as the name says. We might whant to give recommendations for IANA compatible names in another TL;DR copy list for now, since current operating systems already offer v2.3.6.
BTW: Sorry for my editor chopping ending-spaces. 👎