Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding a note on OpenVPN's tls-version-min option. #91

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
8 participants
@doertedev
Copy link

doertedev commented Jan 8, 2015

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. 馃憥

@doerteDev (Stefan Staudenmeyer)
Adding a note on OpenVPN's tls-version-min option.
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.
@doertedev

This comment has been minimized.

Copy link
Author

doertedev commented Jan 8, 2015

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?

@aaronkaplan

This comment has been minimized.

Copy link
Member

aaronkaplan commented Jan 8, 2015

I'd vote yes for that addition (except for the ending-spaces :) . Thanks!
Opinion on TL;DR copy: yes sounds good. Actually, if we can just link to a document listing the most current values, that would be far better than listing all names in the document IMHO.

@doertedev

This comment has been minimized.

Copy link
Author

doertedev commented Jan 8, 2015

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:

  • OV - Version <= 2.3.1: Old non-IANA names + RSA Suites + DHE (for forward secrecy)
  • OV - version <= 2.3.2: TLS 1.0 RSA + DHE (for forward secrecy)
  • OV - version >= 2.3.3: TLS 1.2 if possible and all peers > 2.3.3, else see above.

TLS 1.0 + OpenVPN <= v2.3.1:

  • DHE-RSA-AES256-GCM-SHA384
  • DHE-RSA-AES256-SHA256
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES128-SHA256
  • DHE-RSA-CAMELLIA256-SHA
  • DHE-RSA-AES256-SHA
  • DHE-RSA-CAMELLIA128-SHA
  • DHE-RSA-AES128-SHA
  • CAMELLIA256-SHA
  • AES256-SHA
  • CAMELLIA128-SHA
  • AES128-SHA

TLS 1.0 respectively OpenVPN <= v2.3.2:

  • TLS-DHE-RSA-WITH-AES-256-CBC-SHA
  • TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
  • TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
  • TLS-DHE-RSA-WITH-AES-128-CBC-SHA
  • TLS-DHE-RSA-WITH-SEED-CBC-SHA
  • TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
  • TLS-DHE-RSA-WITH-DES-CBC-SHA

TLS 1.2 (requires all peers having OpenVPN >= v2.3.3):

  • TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
  • TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
  • TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
  • TLS-DHE-RSA-WITH-AES-128-CBC-SHA256

Maybe we can just write a short notice about the TLS / OpenVPN Version constraints resulting in the cipherlists and throw in the two lists? :)
Question to the guys actually knowing crypto: Are there any ciphers we should remove from this list to date?
In the mean time I will try to figure out how to put this in the most simple and shortest way.

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 8, 2015

@doertedev:

Question to the guys actually knowing crypto: Are there any ciphers we should remove from this list to date?

  • every ciphersuite containing CBC mode is broken.
  • 3DES-EDE: well. it's out of scope of our document.

historical note on cipherstring/suite naming:
back in the old days when netscape invented SSL and ssleay (now openssl) was written, there wasn't an actual standard, that came later. In 2006 IANA standardized these ciphersuites and the according numbers. Hence the confusion among TLS libraries and server/client implementations.

@malexmave

This comment has been minimized.

Copy link
Contributor

malexmave commented Jan 9, 2015

every ciphersuite containing CBC mode is broken.

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)

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 9, 2015

@malexmave

This comment has been minimized.

Copy link
Contributor

malexmave commented Jan 9, 2015

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?

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 9, 2015

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.

@malexmave

This comment has been minimized.

Copy link
Contributor

malexmave commented Jan 9, 2015

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.

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 9, 2015

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.

@malexmave

This comment has been minimized.

Copy link
Contributor

malexmave commented Jan 9, 2015

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.

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 9, 2015

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

@doertedev

This comment has been minimized.

Copy link
Author

doertedev commented Jan 9, 2015

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?

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 9, 2015

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.

@doertedev

This comment has been minimized.

Copy link
Author

doertedev commented Jan 12, 2015

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...

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 12, 2015

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,
Aaron

@doertedev

This comment has been minimized.

Copy link
Author

doertedev commented Jan 13, 2015

Well.

$doertedev@trolovo sudo openvpn --show-ciphers
The following ciphers and cipher modes are available for use with OpenVPN. Each cipher shown below may be used as a parameter to the --cipher option. The default key size is shown as well as whether or not it can be changed with the --keysize directive. Using a CBC mode is recommended. In static key mode only CBC mode is allowed.

DES-CFB 64 bit default key (fixed) (TLS client/server mode)
DES-CBC 64 bit default key (fixed)
IDEA-CBC 128 bit default key (fixed)
IDEA-CFB 128 bit default key (fixed) (TLS client/server mode)
RC2-CBC 128 bit default key (variable)
RC2-CFB 128 bit default key (variable) (TLS client/server mode)
RC2-OFB 128 bit default key (variable) (TLS client/server mode)
DES-EDE-CBC 128 bit default key (fixed)
DES-EDE3-CBC 192 bit default key (fixed)
DES-OFB 64 bit default key (fixed) (TLS client/server mode)
IDEA-OFB 128 bit default key (fixed) (TLS client/server mode)
DES-EDE-CFB 128 bit default key (fixed) (TLS client/server mode)
DES-EDE3-CFB 192 bit default key (fixed) (TLS client/server mode)
DES-EDE-OFB 128 bit default key (fixed) (TLS client/server mode)
DES-EDE3-OFB 192 bit default key (fixed) (TLS client/server mode)
DESX-CBC 192 bit default key (fixed)
BF-CBC 128 bit default key (variable)
BF-CFB 128 bit default key (variable) (TLS client/server mode)
BF-OFB 128 bit default key (variable) (TLS client/server mode)
RC2-40-CBC 40 bit default key (variable)
CAST5-CBC 128 bit default key (variable)
CAST5-CFB 128 bit default key (variable) (TLS client/server mode)
CAST5-OFB 128 bit default key (variable) (TLS client/server mode)
RC2-64-CBC 64 bit default key (variable)
AES-128-CBC 128 bit default key (fixed)
AES-128-OFB 128 bit default key (fixed) (TLS client/server mode)
AES-128-CFB 128 bit default key (fixed) (TLS client/server mode)
AES-192-CBC 192 bit default key (fixed)
AES-192-OFB 192 bit default key (fixed) (TLS client/server mode)
AES-192-CFB 192 bit default key (fixed) (TLS client/server mode)
AES-256-CBC 256 bit default key (fixed)
AES-256-OFB 256 bit default key (fixed) (TLS client/server mode)
AES-256-CFB 256 bit default key (fixed) (TLS client/server mode)
AES-128-CFB1 128 bit default key (fixed) (TLS client/server mode)
AES-192-CFB1 192 bit default key (fixed) (TLS client/server mode)
AES-256-CFB1 256 bit default key (fixed) (TLS client/server mode)
AES-128-CFB8 128 bit default key (fixed) (TLS client/server mode)
AES-192-CFB8 192 bit default key (fixed) (TLS client/server mode)
AES-256-CFB8 256 bit default key (fixed) (TLS client/server mode)
DES-CFB1 64 bit default key (fixed) (TLS client/server mode)
DES-CFB8 64 bit default key (fixed) (TLS client/server mode)
DES-EDE3-CFB1 192 bit default key (fixed) (TLS client/server mode)
DES-EDE3-CFB8 192 bit default key (fixed) (TLS client/server mode)
CAMELLIA-128-CBC 128 bit default key (fixed)
CAMELLIA-192-CBC 192 bit default key (fixed)
CAMELLIA-256-CBC 256 bit default key (fixed)
CAMELLIA-128-CFB 128 bit default key (fixed) (TLS client/server mode)
CAMELLIA-192-CFB 192 bit default key (fixed) (TLS client/server mode)
CAMELLIA-256-CFB 256 bit default key (fixed) (TLS client/server mode)
CAMELLIA-128-CFB1 128 bit default key (fixed) (TLS client/server mode)
CAMELLIA-192-CFB1 192 bit default key (fixed) (TLS client/server mode)
CAMELLIA-256-CFB1 256 bit default key (fixed) (TLS client/server mode)
CAMELLIA-128-CFB8 128 bit default key (fixed) (TLS client/server mode)
CAMELLIA-192-CFB8 192 bit default key (fixed) (TLS client/server mode)
CAMELLIA-256-CFB8 256 bit default key (fixed) (TLS client/server mode)
CAMELLIA-128-OFB 128 bit default key (fixed) (TLS client/server mode)
CAMELLIA-192-OFB 192 bit default key (fixed) (TLS client/server mode)
CAMELLIA-256-OFB 256 bit default key (fixed) (TLS client/server mode)
SEED-CBC 128 bit default key (fixed)
SEED-OFB 128 bit default key (fixed) (TLS client/server mode)
SEED-CFB 128 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.

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 13, 2015

Hmmmm. Why isn't AES-GCM in their list? Any ideas?

@ignisf

This comment has been minimized.

@azet

This comment has been minimized.

Copy link
Member

azet commented Jan 13, 2015

@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?

@azet

This comment has been minimized.

Copy link
Member

azet commented Feb 18, 2015

Closing for reasons listed above & missing review by third parties.

@azet azet closed this Feb 18, 2015

azet added a commit that referenced this pull request Feb 18, 2015

@syzzer

This comment has been minimized.

Copy link

syzzer commented Feb 21, 2015

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:

  1. The 'control channel'. This is a low bandwidth control channel, over which e.g. network parameters and key material for the 'data channel' is exchanged'
  2. The 'data channel'. This is the channel over which the actual VPN traffic is sent. This channel is keyed with key material exchanged over the control channel.
    Both these channels are duplexed over a single TCP or UDP port.

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 openvpn --show-tls. With modern crypto libraries, that will include AEAD cipher suites.

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 tls-version-min 1.0 (or 1.1/1.2) in both server and client configs. I would indeed highly recommend doing that. In time, this will be enabled by default, but when we did that in 2.3.3 too many users reported their connections broke down (reportedly amongst others because firewalls no longer correctly recognized OpenVPN connections). The breakage was too big, and we had to revert the change in 2.3.4.

(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.

@azet

This comment has been minimized.

Copy link
Member

azet commented Feb 21, 2015

@syzzer

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.

@azet azet reopened this Feb 21, 2015

@syzzer

This comment has been minimized.

Copy link

syzzer commented Feb 21, 2015

@azet

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 tls-cipher option. This option takes a colon-separated cipher string, either in IANA of OpenSSL format (when using OpenSSL, ofc).

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.

azet added a commit that referenced this pull request Mar 16, 2015

@dicer

This comment has been minimized.

Copy link

dicer commented May 2, 2015

@syzzer
When you say one should disable compression on a hardened system by default, are you talking about comp-lzo?

@syzzer

This comment has been minimized.

Copy link

syzzer commented May 2, 2015

@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.

@azet

This comment has been minimized.

Copy link
Member

azet commented May 14, 2015

closing this for now. feel free to comment.

@azet azet closed this May 14, 2015

Harvester57 added a commit to Harvester57/OpenVPN-install that referenced this pull request Mar 21, 2016

Disable compression
For a hardened OpenVPN configuration, compression should be disabled : BetterCrypto/Applied-Crypto-Hardening#91 (comment)

@Harvester57 Harvester57 referenced this pull request Mar 21, 2016

Merged

Disable compression #1

@angristan

This comment has been minimized.

Copy link

angristan commented Mar 21, 2016

Hello,

Is it better to disable compression even if we force TLS 1.2 ?

@azet

This comment has been minimized.

Copy link
Member

azet commented Mar 21, 2016

@angristan

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.

@angristan

This comment has been minimized.

Copy link

angristan commented Mar 21, 2016

I thought maybe it was related to the old SSLv3 compression flaw. ^^
Thanks.

@azet

This comment has been minimized.

Copy link
Member

azet commented Mar 21, 2016

@angristan

Which SSLv3 compression flaw do you mean?

Thanks,
Aaron

@angristan

This comment has been minimized.

Copy link

angristan commented Mar 21, 2016

@azet I can't find it anymore, sorry 馃槩

@azet

This comment has been minimized.

Copy link
Member

azet commented Mar 21, 2016

I'm not aware of SSLv3 specific compression vulnerabilities. They are (for now) not restricted to a certain iteration of the protocol.

fkooman added a commit to eduvpn/vpn-server-api that referenced this pull request Mar 23, 2016

@stephdl stephdl referenced this pull request May 17, 2018

Closed

Harden openvpn Tunnel #5498

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.