(866) 978-3698

In the face of an ever evolving threat landscape, VENYU wants to make sure that your network and data is as secure as possible. VPN’s are almost a necessity for today’s business requirements, but organizations must be mindful of their VPN configuration. Whether you utilize a IPsec tunnel for a site-to-site VPN or for remote access, it’s important to take appropriate configuration steps to make sure they are as secure as possible against modern day threats. Without delving into too much technical detail, advancements have been made to VPN technology in order to protect data. Algorithms developed in the early days of digital data encryption are no longer secure because of advancements in computing. Because of this, it’s important to make sure that your organization is keeping up with the latest in standards to protect your sensitive data. The intent of this document is to make you aware of what should be avoided regarding VPN configurations and what should be used instead. Note: This is not an exhaustive list containing every step of a VPN configuration, but focuses on some of the known deficiencies seen. These recommendations are also subject to change as new cryptographic algorithms are developed and existing algorithms are deemed no longer secure.

What to Avoid

The configuration of phase 1 and phase 2 proposals for tunnel creation are one area in which many organizations continue to use insecure or legacy algorithms for encryption and authentication. DES (Data Encryption Standard), which is used for encryption, is considered insecure due to its short key size and should not be used. 3DES is a strong form of DES, but is considered by NIST to either be legacy, deprecated, or disallowed depending upon number of keys used.  For this reason, it’s Venyu’s recommendation, that 3DES be avoided as well. The SHA-1 and MD5, (often known as hashing algorithms) which are used for authentication, are both considered broken, and should not be used in VPN configurations. DH (Diffie-Hellman) algorithms, used for key exchange, should not be used for groups with a bit value of 1024 or less. Some organizations utilize a shared PSK (pre-shared keys) for authentication between a VPN server and all remote access VPN clients. This practice is strongly discouraged as an attacker can impersonate any client or the VPN server itself if they attain the PSK. PSKs that are used for IPsec tunnels, should not be derived from dictionary words and should instead by randomly generated. PSKs should also not be stored by either party when creating a VPN tunnel. If a change is required that needs the PSK, a new PSK should be created.

What to Use

Now that we’ve covered, what algorithm’s to avoid, let’s discuss what to use instead. AES should be used as an alternative for DES and 3DES. AES comes in different bit length key forms and although, AES-128 provides adequate protection, it’s best if AES-256 can be used. AES requires a stronger DH group than DES or 3DES and for this reason, it’s recommended that groups of 2048-bith modulus or higher are used (groups 15, 16, 17, and 18) and preferably groups that employ Elliptic Curve Cryptography (groups 19, 20, 21). Due to the recommendation of the higher DH groups, and the inability for IKEv1 to support these groups, it’s recommended that IKEv2 be used instead. It should be noted that IKEv2 has other improvements over IKEv1 that won’t be covered in this document due to scope. According to NIST, the recommended hashing algorithms utilized for authentication, should either be SHA-2 or SHA-3. Common SHA-2 hashing algorithms include SHA-256, SHA-384, and SHA-512. NIST encourages at least SHA-256, but Venyu recommends SHA-512 if it’s supported. PFS should always be enabled for VPN tunnels as it allows for IPsec endpoints to change session keys frequently. This protects the confidentiality of the data in the event that the PSK is compromised.

Assistance

As always if you have additional questions, would like someone to review your firewall settings with you or need assistance with a change please open a support case using the customer portal (https://portal.myvenyu.com/)

Quick Reference

Encryption Algorithms Recommendation
DES Don’t use
3DES Don’t use
AES-128 Acceptable
AES-192 Acceptable
AES-256 Preferred

 

Authentication Algorithms Recommendation
MD5 Don’t use
SHA-1 Don’t use
SHA-256 Acceptable
SHA-384 Acceptable
SHA-512 Preferred

 

Key-Exchange Algorithms Recommendation
Group 1 Don’t use
Group 2 Don’t use
Group 5 Don’t use
Group 14 (modulus 2048) Minimum acceptable (only available in IKEv2)
Group 15 (modulus 3072) Acceptable (only available in IKEv2)
Group 16 (modulus 4096) Acceptable (only available in IKEv2)
Group 17 (modulus 6144) Acceptable (only available in IKEv2)
Group 18 (modulus 8192) Acceptable (only available in IKEv2)
Group 19 (ECC) Acceptable (only available in IKEv2)
Group 20 (ECC) Acceptable (only available in IKEv2)
Group 21 (ECC) Preferred

 

References

CMU Software Engineering Institute Vulnerability Note on MD5
https://www.kb.cert.org/vuls/id/836068

NIST Policy on Hash Functions
https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions

NIST Special Publication 800-131A – Revision 2
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf

NIST Special Publication 800-77 – Revision 1
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-77r1.pdf

Cisco Next Generation Cryptography
https://tools.cisco.com/security/center/resources/next_generation_cryptography

Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/04/imperfect-forward-secrecy-ccs15.pdf

Additional Diffie-Hellman Groups for Use with IETF Standards
https://tools.ietf.org/html/rfc5114