How To:Secure Windows 10 IKEv2 VPNs. Improve IKEv2 security strength -the easy way. Enable hidden support for advanced cryptographic algorithms on Windows clients.
Problem:The default Windows implementation of IPsec is highly vulnerable to Man-in-the-Middle (MITM) attacks. It uses depreciated security algorithms and should not be trusted. DO NOT use IKEv2 or L2TP/IPsec with Windows clients unless it negotiates secure cryptographic algorithms.
Solution:A simple registry change enables secure IPsec. This easy fix provides a respectable DH14-AES256-SHA256 negotiation. Alternately, use PowerShell to enable even stronger security. Both solutions provide a cryptographic baseline that ensures secure communications.
Background:The VPN server confirms vulnerable security: 3DES, SHA1, and DH2 -all bad. Confirm active MM cryptographic algorithms with PowerShell:
3DES? SHA1? DH2? Good thing we checked!
PS C:\Users\stevenuwm> Get-NetIPsecMainMode Name : 51 LocalEndpoint : x.x.x.x RemoteEndpoint : x.x.x.x LocalFirstId.AuthenticationMethod : Certificate CipherAlgorithm : AES256 HashAlgorithm : SHA1 KeyModule : IkeV2 CipherAlgorithm : DES3 HashAlgorithm : SHA1 GroupId : DH2 KeyModule : IkeV1
Security Guidelines:The Internet Engineering Task Force (IETF) provides guidelines for securing IKEv2. (RFC4307 BIS-13). These standards are based on key management security strength. Do not use any cryptographic algorithm with less than 103-bits of security: http://www.stevenjordan.net/2016/09/ipsec-security-levels.html.
Key Management Tips:
- DH Group-2 SHOULD NOT be used.
- Use DH Group-14.
- Use RSA-3096 certificates.
- Use AES128 encryption.
- SHA1 (Main-Mode) can be used. SHA256 is a better alternative.
- Use HMAC-SHA1. It is not the same thing as SHA1
Registry Solution:Create a registry key that enforces modern cipher and transform sets.
STEP 1: Edit Registry or create GPO:
STEP 2: Create new DWORD value:
STEP 3: Modify DWORD value:
Table 2: NegotiateDH2048_AES256 Values.
|Value||IKEv2 Security||L2TP\IPsec (i.e., IKEv1)|
|1||MM: IKE-DH14-AES256- SHA1
|2||M: IKE-DH14-AES256- SHA256
No value, or value of 0 uses client defaults -weak encryption and hash!
VPN client security MUST be set to maximum strength encryption in it property settings.
NegotiateDH2048_AES256 Data Type: Reg_DWORD
Windows VPN Server:IPsec requires common cryptographic algorithms. Windows 2012 IPsec is every bit as insecure as Windows 10. Therefore we'll need to make adjustments to the server as well.
The above registry fix is recommended for Windows clients. However it can work with Windows 2012 RRAS VPN server -with one catch. It does improve security strength for DH and encryption, It does not improve the security strength for the hashing:
This registry change meets the bare-minimum IETF recommendations for IKEv2. It's better than before -but we can do better.
Should we trust SHA1? It's probably OK for now. On the other hand, Google Chrome and Microsoft IE no longer support certificates that use SHA1. Weak hashes (e.g., SHA1) are vulnerable to sophisticated off-line attacks In other words, an attacker can steal your identity! (Entrust 2014).
We're not talking about credit scores. We're talking about digital identity and authentication. Fake RSA signatures that authenticate to the VPN, email, etc. Yikes!
Why risk SHA1 when we can easily implement SHA256? There are other simple (yet hard to find) methods that improve IKEv2 security strength on Windows servers. We can do better: http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html
PowerShellThe Windows 10 registry fix is the path of least resistance. However, PowerShell supports a wider range of cryptography algorithms. N.B., These IPsec configurations are not available from the Windows GUI or registry.
Step 1: Configure new IKEv2 VPN.
Create the new VPN connection with PowerShell. Do not create the VPN connection with the GUI.
However, it's OK to use the GUI to edit authentication attributes after PowerShell creates the connection .
Step 2: Configure an acceptable level of cryptography.
Add-VpnConnection -Name "IKEv2-VPN" -ServerAddress "vpn.stevenjordan.net" -TunnelType IKEv2 -AuthenticationMethod MachineCertificate
Set-VpnConnectionIPsecConfiguration -ConnectionName "IKE-SMJ" -AuthenticationTransformConstants None -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru -AllUserConnection AuthenticationTransformConstants : None CipherTransformConstants : AES256 DHGroup : Group14 IntegrityCheckMethod : SHA256 PfsGroup : None EncryptionMethod : AES256 PfsGroup : None
Additional Thoughts:Why does Microsoft cripple IPsec VPN security by default? Is it support for legacy devices? Are there more nefarious reasons (e.g., Eric Snowden)? Does it nudge folks away from IPsec toward SSTP? If so it's as good of a reason as any! In fact, I recommend SSTP for most situations. The only problem with SSTP is that it's limited to Windows and Android clients. Direct Access is another great VPN solution (that incorporates Windows IPsec).
Conclusion:In the end, NegotiateDH20148_AES256, is a Band-Aid for its default (i.e., broken) Windows IKEv2 VPN. It provides bare-minimum IPsec security strength that should already be enabled by default. The registry fix may not be the best option but it's quick and it's easy.
On the other hand, Windows 10 supports stronger IKEv2 security strength via PowerShell commands. By default, Windows IPsec VPN is not secure -it should not be trusted. However, these VPNs can provide excellent security with a few simple changes.
Microsoft Windows 8 Windows Server 2-12 Supplemental Admin Guidance IPsec VPN Clien.docx. https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-00