Bug #8594
closedAssess default crypto settings for OpenVPN/IPsec
0%
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
Updated by Anonymous over 6 years 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?
Updated by Anonymous over 6 years ago
Additionally, I'd like to make two additional changes:
- Add a 6144-bit option to the CA and Cert Manager pages (to match the 6144-bit DH group from the RFC 7919 changes)
- 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?
Updated by Anonymous over 6 years ago
PR for proposed changes: https://github.com/pfsense/pfsense/pull/3954
Obviously, PR commits are subject to change based on discussion.
Updated by Jim Pingle over 6 years ago
- Category set to VPN (Multiple Types)
- Assignee set to Jim Pingle
- Target version set to 2.4.4
- Affected Version set to All
- Affected Architecture All added
- Affected Architecture deleted (
)
Updated by Jim Pingle over 6 years 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.
Updated by Anonymous over 6 years 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.
Updated by Jim Pingle over 6 years 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.
Updated by Anonymous over 6 years ago
I can open up a separate issue and work on it, if you think it's worthwhile.
Updated by Jim Pingle about 6 years ago
- Status changed from Feedback to Resolved