Project

General

Profile

Bug #8594

Assess default crypto settings for OpenVPN/IPsec

Added by Justin Coffman 11 months ago. Updated 10 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
VPN
Target version:
Start date:
06/22/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
All
Affected Architecture:
All

Description

Per Jim's comment on https://github.com/pfsense/pfsense/pull/3951. If any changes are approved, I'll be happy to submit a PR to implement.

Current default crypto parameters for OpenVPN are the OpenVPN project defaults. Unfortunately, these defaults have not tracked with cryptographic best practices. The default encryption algorithm (Blowfish) uses a 64-bit block size, rendering it vulnerable to birthday attacks (e.g. SWEET32). The default authentication algorithm (SHA1) has been deprecated for cryptographic usage since 2005, with demonstrated collisions since 2017.

pfSense's default selections beyond these elements are also in need of updates. The default DH group size for OpenVPN is 1024 bits, which is small enough that it is considered at least theoretically vulnerable to compromise against well-funded adversaries. The default selections for IPsec tunnels (both phase 1 and phase 2) have similar issues: the default hash is SHA1, using DH group 2 (1024 bits) for phase 1, and no PFS group for phase 2.

Current cryptographic best practices as published by US NIST [1] and the German Federal Office for Information Security [2] provide, in general, two sets of recommendations:

For routine cryptographic usage (where security must be maintained for three years or less):

Symmetric encryption algorithms (AES, CAMELLIA, CHACHA20, etc.) should use a key of at least 128 bits in length, with a block size of at least 128 bits.
Integer factorization-based asymmetric cryptosystems (RSA, traditional Diffie-Hellman, etc.) should use a modulus (key size, DH parameter length) of at least 2048 bits in length.
Elliptic curve-based asymmetric cryptosystems (ECDSA, elliptic curve Diffie-Hellman, etc.) should use a key length of at least 256 bits.
Authentication and integrity algorithms (SHA-2, POLY1305, etc.) should produce digest outputs (hashes) of at least 256 bits in length.

For long-term cryptographic usage (where security must be maintained for greater than three years):

Symmetric encryption algorithms should use a key of at least 128 bits in length, with a block size of at least 128 bits.
Integer factorization-based asymmetric cryptosystems should use a modulus of at least 3072 bits in length.
Elliptic curve-based asymmetric cryptosystems should use a key length of at least 256 bits.
Authentication and integrity algorithms should produce digest outputs of at least 256 bits in length.

In light of these recommendations, I propose to update defaults to the following:

OpenVPN:
Cipher: AES-128-CBC (OpenVPN's NCP configuration will still override this with compatible clients)
NCP Ciphers: AES-128-GCM
Auth Digest: SHA256
DH Size: 2048

IPsec Phase 1:
Encryption Algorithm: AES-128
Hash: SHA256
DH Group: 14 (2048 bits)

IPsec Phase 2:
Encryption Algorithms: AES, AES-128GCM
Hash Algorithms: SHA256
PFS Key Group: Group 14 (2048 bits)

These recommendations provide at least the minimum recommended cryptographic strength while also allowing for decent performance in both hardware and software cryptographic implementations.

AES-128 is recommended over AES-256 for several reasons: First, AES-256 does not provide a meaningful increase in security over AES-128. Second, AES-256 incurs a roughly 40% performance penalty over AES-128, a significant margin that is made even more noticeable when run on platforms that do not provide hardware acceleration for cryptographic primitives. Third, these selections align to, roughly, a 128-bit security level. Using a larger symmetric key yields little real benefit without an accordant increase in DH group size and digest size.

Note that this proposal does not deprecate any existing capability. No algorithms are being removed. This is only to update the defaults for new configurations, and does not modify any existing deployment. This is especially critical for IPsec tunnels, as many large public cloud providers still require the use of deprecated cryptosystems.

[1] Barker, E. (2016). Recommendation for Key Management, Part 1: General (SP 800-57 Part 1 Rev. 4). Retrieved from National Institute of Standards and Technology website: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-4/final

[2] Bundesamt für Sicherheit in der Informationstechnik. (2018). Kryptographische Verfahren: Empfehlungen und Schlüssellängen (TR-02102-1 v2018-02). Retrieved from https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf

History

#1 Updated by Justin Coffman 11 months ago

Additionally, I'd like to make two additional changes:

1. Add a 6144-bit option to the CA and Cert Manager pages (to match the 6144-bit DH group from the RFC 7919 changes)
2. Remove the 512-bit option from the same pages. These keys are so small that they're trivially breakable (in 2015, it could be done on AWS with four hours and US $75). Is there any good reason to allow this option to continue existing?

#2 Updated by Justin Coffman 11 months ago

Additionally, I'd like to make two additional changes:

  1. Add a 6144-bit option to the CA and Cert Manager pages (to match the 6144-bit DH group from the RFC 7919 changes)
  2. Remove the 512-bit option from the same pages. These keys are so small that they're trivially breakable (in 2015, it could be done on AWS with four hours and US $75). Is there any good reason to allow this option to continue existing?

#3 Updated by Justin Coffman 11 months ago

PR for proposed changes: https://github.com/pfsense/pfsense/pull/3954

Obviously, PR commits are subject to change based on discussion.

#4 Updated by Jim Pingle 11 months ago

  • Category set to VPN
  • Assignee set to Jim Pingle
  • Target version set to 2.4.4
  • Affected Version set to All
  • Affected Architecture set to All

#5 Updated by Jim Pingle 11 months ago

Justin Coffman wrote:

Additionally, I'd like to make two additional changes:

1. Add a 6144-bit option to the CA and Cert Manager pages (to match the 6144-bit DH group from the RFC 7919 changes)
2. Remove the 512-bit option from the same pages. These keys are so small that they're trivially breakable (in 2015, it could be done on AWS with four hours and US $75). Is there any good reason to allow this option to continue existing?

Those are both fine. The older/smaller sizes had been kept around because at some point there were some older embedded clients that did not work with larger values, but that was quite some time ago. If anyone needs something that small these days, they have larger problems than needing to add it back into the list manually. They can maintain that change themselves if they need it.

#6 Updated by Justin Coffman 11 months ago

Would it be valuable to include some validation logic in the interface to warn a user if they select an algorithm with known weaknesses? For example, if someone selects Blowfish, DES, or RC5, the interface would bring up a warning that the chosen algorithm is vulnerable to SWEET32. If they select SHA1 or MD5, it would warn that that algorithm has known collisions and/or is no longer recommended for cryptographic usage.

#7 Updated by Jim Pingle 11 months ago

Justin Coffman wrote:

Would it be valuable to include some validation logic in the interface to warn a user if they select an algorithm with known weaknesses? For example, if someone selects Blowfish, DES, or RC5, the interface would bring up a warning that the chosen algorithm is vulnerable to SWEET32. If they select SHA1 or MD5, it would warn that that algorithm has known collisions and/or is no longer recommended for cryptographic usage.

Maybe eventually but I would consider that a separate issue unrelated to this. There are also some other various security issues that could be flagged as noted on https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites like the DH Group 22-24 prime sources.

#8 Updated by Justin Coffman 11 months ago

I can open up a separate issue and work on it, if you think it's worthwhile.

#9 Updated by Jim Pingle 10 months ago

  • Status changed from New to Feedback

PR Merged

#10 Updated by James Dekker 10 months ago

On 2.4.4.a.20180726.0918, looks good.

#11 Updated by Jim Pingle 10 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF