IPSec Fail: Perfect Forward Secrecy, Where Art Thou?

Perfect Forward Secrecy (PFS) has garnered widespread publicity in recent months thanks to Snowden and the NSA. As a result, an increasing number of websites and email service providers have been pushing for PFS to provide better security to their users.

PFS protects previous key exchanges even if the current one is compromised.

Unfortunately the same cannot be said about current popular IPSec VPN clients. Neither of the ones I tested – all of them from recent distributions including Windows and OS X – offered PFS out of the box, meaning previous IPSec key exchanges could be decrypted by an attacker if the current one is compromised.

NSOC-2012

IPSec with PFS disabled

In IPSec, the Diffie-Hellman group is configured as part of the Phase I key exchange. This is the shared master key. During a Phase II negotiation, a new key is generated which is derived from the master key material of Phase I.

  • an initial Diffie-Hellman exchange is performed in Phase 1 during IKE startup
  • subsequent keying material in each Phase 2 negotiation is deterministically derived from the initial Diffie-Hellman shared keying material
  • an attacker breaking the initial keying material at any stage can also reconstruct all other rekeyed material

IPSec with PFS enabled

If PFS is enabled and proposed by both IPSec peers, generated keys in Phase 2 negotiations are not related in any way.

  • an initial Diffie-Hellman exchange is performed in Phase 1 during IKE startup
  • subsequent keying material in each Phase 2 negotiation is generated from a separate Diffie-Hellman exchange without dependence on previous keys (including the initial keying material)
  • if keying material is compromised only data encrypted with that material is compromised.

Findings: No Perfect Forward Secrecy in common IPSec clients

The IPSec specs support PFS as an option (RFC 2412). Yet, neither of the tested VPN clients gives you PFS out of the box.*

* Not an out of the box solution, but with Windows 7 and 8, for example, you could skip the point-and-shoot agile VPN client and instead manually configure IPSec with PFS by using the built-in Windows firewall and the supported Suite B cryptographic algorithms.

You may counter that IPSec with PFS enabled is computationally intensive. This may be true if you are using a Diffie-Hellman exchange with a prime modulus group, but you could just as well improve performance again by using an elliptic curve group instead.

I think it’s about time that vendors consider making PFS an accessible option for everyone of us.

Test Raw Data

iOS 7.1 built-in IPSec client

IKE:

received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024

ESP:

received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ

Android built-in IPSec client (4.1.2)

IKE:

received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024

ESP:

received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_MD5_96/NO_EXT_SEQ

strongSwan VPN client (Android) V1.3.3

IKE:

received proposals: IKE:3DES_CBC/AES_CBC_128/AES_CBC_192/AES_CBC_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/HMAC_MD5_96/HMAC_SHA1_96/AES_XCBC_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/MODP_1024/MODP_1536/MODP_2048/MODP_3072/MODP_4096/MODP_8192/ECP_256/ECP_384/ECP_521/MODP_1024_160/MODP_2048_224/MODP_2048_256/ECP_192/ECP_224/ECP_224_BP/ECP_256_BP/ECP_384_BP/ECP_512_BP

ESP:

received proposals: ESP:AES_GCM_16_128/AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_384_192/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/NO_EXT_SEQ

Mac OS X 10.9.2 build-in IPSec client

IKE:

received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024

ESP:

received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ

Windows 7 built-in IPSec IKEv2 client

“Maximum strength encryption (disconnect if server declines)”

IKE:

received proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024

ESP:

received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ

(same results with the Window 8.1 Agile VPN client)

Image credits: Wikipedia

3 thoughts on “IPSec Fail: Perfect Forward Secrecy, Where Art Thou?”

  1. I was staring in disbelief at https://technet.microsoft.com/en-us/library/dd125380(v=ws.10).aspx , where Microsoft claims that already Windows XP supports MODP_2048 (dhgroup14). In the Windows 7 IKE proposals you posted, MODP_2048 is nowhere to be found.

    So I tested against Windows 10 (see below). The list got longer, but again, no MODP_2048. Considering that MODP_1024 must be considered broken acc. to https://weakdh.org/ , you have to wonder what the hell Microsoft is doing here.

    WINDOWS 10 BUILT-IN IPSEC IKEV2 CLIENT

    “Maximum strength encryption (disconnect if server declines)”

    received proposals: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_192/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024

    Reply

  2. I was configuring an IPSec server, only to find that my Windows 8.1 only supported the DH group2 (MODP_1024) as well… but only in the GUI.

    You can configure stronger DH groups using powershell, in particular on my Windows 8.1, I have access to dhgroup14 (MODP_2048), ECP256 (dhgroup19) and ECP384 (dhgroup20) (both are safe).

    Here is how to do it : https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps

    Personally, I created the connection using the GUI and configured everything there. Once done, I used powershell to type the following command :

    Set-VpnConnectionIPsecConfiguration -ConnectionName “IPSec VPS” -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -CipherTransformConstants AES256 -AuthenticationTransformConstants SHA256128 -PfsGroup ECP256

    EncryptionMethod : Main Mode (IKE Phase 1) encryption cipher
    IntegrityCheckMethod : Main Mode (IKE Phase 1) hash function
    DHGroup : Diffie-Hellman group
    CipherTransformConstants : Quick Mode (IKE Phase 2, child SAs) encryption cipher
    AuthenticationTransformConstants : Quick Mode (IKE Phase 2) hash function
    PfsGroup : Perfect Forward Secrecy DH group used (if set to None, then PFS is not used)

    I believe if Aggressive mode is used instead of Main Mode, then the Main Mode settings would be used. I did not test this though.

    I tried to use AES256GCM (which is in fact aes256gcm16, the 128 bit ICV variant) for CipherTransformConstants and AuthenticationTransformConstants, but it does not work. I believe there is a bug in Windows. AES256GCM is an AEAD, and thus removes the need for a separate integrity check (and improves performance).

    Hope this will help somebody someday !

    Reply

Leave a Reply

Your email address will not be published.