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

One thought 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

Leave a Reply

Your email address will not be published. Required fields are marked *