pfSense

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