Jump to content
Not connected, Your IP: 52.55.214.236
iampd

ANSWERED Which TLS cipher suite should be used ?

Recommended Posts

Hi, I am not sure if this has been discussed before or if this is the right forum to post it. Kindly correct if there's any issue.

While connecting to AirVPN through openvpn client using .opvn configs, the control channel always shows TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 as the cipher suite in the logs throughout all the servers/countries.

Since openvpn supports both: TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384; TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 of these ciphers suites, why aren't they the default encryption suites for the connection?

   ECDHE    and   ECDSA   provide  better security than   DHE   and  RSA , respect ively. ECDSA  clear  ly has an advantage of providing similar security over much smaller key space than  RSA , although ECC verifying takes a bit more time. Is the overhead time a concern to not switch to these  cipher suites, or is there any other reason ? Please explain.

Thank you.

 

Share this post


Link to post

 Hello!

 

Since openvpn supports both: TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384; TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 of these ciphers suites, why aren't they the default encryption suites for the connection?

 

For a precise choice we explained several times in the past. Feel free to search the forum.

 

ECDHE    and   ECDSA   provide  better security than   DHE   and  RSA , respect ively.

 

This is questionable, especially since you don't specify parameters. In 2007 Schneier expressed some doubts about NSA backdoors in ECC, and we have always followed a vary conservative approach against NIST-recommended ECs.

 

Later in 2013 the documents revealed by Snowden showed that backdoors were indeed implemented by NSA in the ellyptic curve bit generator Dual_EC_DRBG, and that a vast program to implement backdoors on various ciphers and have those very ciphers approved as standards was active in NSA.  Therefore facts proved that we were right, and any conservative approach is not a bad thing.

 

See also... the suspicions:

https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters

https://www.wired.com/2007/11/securitymatters-1115/

 

and the first paramount revelation:

https://en.wikipedia.org/wiki/Dual_EC_DRBG

 

About your last question on overhead time, this becomes very relevant in packets verification. Currently there is no reason to add a significant computational burden (which would be relevant on the server side as well) on the Data Channel by shifting from HMAC SHA1 to, for example, HMAC SHA384, even if OpenVPN supported it on the Data Channel (and it doesn't).

 

Kind regards

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...