PIA Not Vulnerable to Weak Diffie-Hellman Key Exchange

SupportSupport
in Privacy News
Dear Customers,

Thank you for choosing Private Internet Access as your VPN provider. As you may have heard being discussed in the news media recently, new research has suggested that the NSA may be able to intercept certain types of private key exchange used in VPN cryptography. More details can be found in the below article published by the EFF:


We would like to reassure our users that PIA does not use the vulnerable 1024-bit Diffie-Hellman key exchange, as targeted by this attack. All VPN connections to our network use a stronger key exchange (2048-bit for OpenVPN, 1536-bit for our iOS app), and are not affected by this disclosure.

If you have any concerns about this, please feel free to contact PIA support.

Best Regards,
PIA

Comments

  • catcher749catcher749
    The OpenVPN key is 1024 bit, so what am I missing here?
  • vic123vic123
    It would be nice if PIA can expand this a bit and see how we can check if we're vulnerable or not.  Many of us do not use the OpenVPN client that is posted on the site and can use a bit of help to check.  

    I *think* it's using 2048 bit, but could use a bit of assistance.  In my OpenVPN logs, I have the following:

    Oct 16 16:02:45 openvpn[18748]: Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
    Oct 16 16:02:45 openvpn[18748]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Oct 16 16:02:45 openvpn[18748]: Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
    Oct 16 16:02:45 openvpn[18748]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Oct 16 16:02:45 openvpn[18748]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

    It's a bit concerning seeing AES-128 instead of AES-256, but AFAIK, OpenVPN only allows aes-256 on their own version of the client software.  

    In any case, it would be nice to validate this is what we should be looking for in the logs...
  • SupportSupport
    @catcher749
    The certificate used for authentication is separate from the Diffie-Helman key exchange group (the certificate prevents active attacks, the key exchange prevents passive attacks).  They can be completely different bit lengths.  Even if the certificate you're using is 1024bit our setup still uses a 2048bit Diffie Helman group (this has been the case for years).  (We are working on a backwards compatible change so you can use a 2048bit certificate as well, which should be coming soon).

    In terms of verifying the Diffie Helman group size of your connection, this is more difficult.  It doesn't show up anywhere in the logs and generally isn't ever shown when viewing details of a TLS connection.  I have confirmed you can verify this using wireshark if you follow these steps:

    - Get the latest stable version of wireshark (older versions won't show it)
    - Start capturing packets
    - Connect to the VPN
    - Stop capturing packets
    - Find the VPN connection in the packet log by looking for the port you are connecting to
    - Right click on it -> Decode As -> OpenVPN
    - Go back to the packet log and look for TLSv1.2 "Server Hello, Certificate, Server Key Exchange..."
    - Click on it
    - In the bottom pane expand Secure Socket Layer -> TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange -> Handshake Protocol: Server Key Exchange -> Diffie-Helman Server Params

    "p Length" is the lenght of the DH group in bytes.  So 256 corresponds to 2048bit.
  • catcher749catcher749
    edited October 2015
    @Support Thanks for the response. I'd still prefer 4096 size keys considering 2048 is considered weak by today's standards. When will these enhanced encryption options be available for OpenVPN users?
  • vic123vic123
    In terms of verifying the Diffie Helman group size of your connection, this is more difficult.  It doesn't show up anywhere in the logs and generally isn't ever shown when viewing details of a TLS connection.  I have confirmed you can verify this using wireshark if you follow these steps:

    - Get the latest stable version of wireshark (older versions won't show it)
    - Start capturing packets
    - Connect to the VPN
    - Stop capturing packets
    - Find the VPN connection in the packet log by looking for the port you are connecting to
    - Right click on it -> Decode As -> OpenVPN
    - Go back to the packet log and look for TLSv1.2 "Server Hello, Certificate, Server Key Exchange..."
    - Click on it
    - In the bottom pane expand Secure Socket Layer -> TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange -> Handshake Protocol: Server Key Exchange -> Diffie-Helman Server Params

    "p Length" is the lenght of the DH group in bytes.  So 256 corresponds to 2048bit.
    Thank you for the response.  I'll see if I can get some free time tonight to run through this, but so far, I feel pretty confident about the response and that PIA is doing stuff right.  :)
  • SupportSupport
    You can use a 4096bit RSA certificate and 4096bit DH group with either our application or our custom openvpn binaries or by compiling openvpn yourself with our patch.  We don't include it and most likely don't plan to for our stock openvpn connections.  Although this is something we'll reconsider going forward.

    The reason for this is that there is no indication that 2048bit is or will be weak.  The vast recommendation of cryptographers is that 2048bit will be strong enough for the forseeable future assuming no new crypto breakthroughs.  Many also think that if 2048bit is broken then it will be likely that all crypto based on discrete logs is broken (i.e. 4096bit Diffie Helman as well) and we will need to move to elliptic curve.  At this point it looks like Daniel Bernstein's Curve25519 and Ed25519 show the most promise.  Once they are standardized for TLS usage and added to OpenSSL we will most likely move to them as the default for certificate and key exchange.  

    Also, realize that although 2048 is only 2 times 1024, a 2048bit number is 2^1024 as large as a 1024bit number.  That is: 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 times as large.  So moving from breaking 1024bit keys to 2048bit keys is not a simple task.

Sign In or Register to comment.