• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Elliptic Curves ciphers suite with sw-nginx (Plesk)

EugeneNSK

New Pleskian
Hi,

I am testing our Plesk linux-server (Plesk 12.0.18 on RHEL 6.6 x64) for SSL high security configuration with Qualys SSL Labs reccomendations (https://www.ssllabs.com/ssltest/).

Best choise today is using Elliptic Curves Ciphers Suite for secure-connection negotiating, but I could not force plesk-contributed sw-nginx to using elliptic curves ciphers suite (sw-nginx-1.6.0-1.14051516.rhel6.x86_64):
when place ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDH+AESGCM; to nginx server and vhost configurations, then secure negotiation is not established.

Starting from RHEL6.5 Red Hat contribute openssl with EC ciphers - https://access.redhat.com/documenta...erprise_Linux/6/html-single/6.5_Release_Notes (openssl-1.0.1e-30.el6_6.4.x86_64)

OpenSSL on live system shows these ciphers:
openssl ciphers -v | grep ECDHE
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
...

I think, the problem is that the sw-nginx is compiled with old openssl binaries without elliptic curves support.

Can Plesk development team recompille and release updated sw-nginx package

or

Сan use genuine nginx package from official nginx repository instead of sw-nginx package?

Thanks for reply!
 
Could you please define, WHY ECC should be prefered on a scientifically based reason? Signature verifications are much faster with RSA than with ECC and this is one reason, why server administrators prefer using RSA.

Another reason why Plesk should not change anything regarding this issue, is the fact, that RSA is STILL the world-wide standard and with the correct configurations, there is only a security advantage for Elliptic Curves, if you view the mathematical base of it's usage. The implementation of ECC is still in development and this is another reason, why Plesk should not consider using it as a standard, but may consider a change in the future, when more implementations are done. Software and hardware technology are far slower than the ECC development and to still guarantee a very wide possible usage, we will have to wait for both, before we should consider changing standards.


Please don't give too much on NSA - headlines, trying to crack encryptions with a quantum computer. This is nonsens at the moment and will be for the next 50 years, because even if a processor could theoretically do it, there is no conventional memory which could cope with it. Even a whole server farm of quantum computers is not able to encrypt an RSA - SHA-2 - key at the moment.
 
Could you please clarify a little bit - what sort of records in what config files you write exactly?
Also this article may be useful for understanding how to write custom records for nginx - http://kb.odin.com/en/120083
 
BTW, we use system openssl:

# ldd /usr/sbin/nginx | grep "ssl\|crypto"
libssl.so.10 => /usr/lib/libssl.so.10 (0xb767e000)
libcrypto.so.10 => /usr/lib/libcrypto.so.10 (0xb74b7000)
 
This settings are works for me in Chrome

ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDH+AESGCM;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

and are not working in FireFox 33.0.3 with "ssl_error_no_cypher_overlap".
 
Thanks for your answers!

Could you please define, WHY ECC should be prefered on a scientifically based reason? Signature verifications are much faster with RSA than with ECC and this is one reason, why server administrators prefer using RSA.
.....
Interesting opinion, but I disagree with this. I have no doubt that RSA is a crypto-resistant standard, but ECC suite is sufficiently widespread to using.

For configuring SSL\TLS I follow the Mozilla Guide (https://wiki.mozilla.org/Security/Server_Side_TLS) which recommended using ECDHE ciphers prefer, and I see no logical option for not using them.

I repeat steps as described in KB (http://kb.odin.com/en/120083), and set values:
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDH+AESGCM;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# openssl s_client -connect fqdn:443
returns error
CONNECTED(00000003)
139933917251400:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:744:
That means that server software (in this case - nginx) does not support ECDHE-RSA-AES256-GCM-SHA384 cipher.

# rpm -qi sw-nginx
Name : sw-nginx Relocations: (not relocatable)
Version : 1.6.0 Vendor: nginx inc.
Release : 1.14051516.rhel6 Build Date: Чтв 15 Май 2014 16:31:46
Install Date: Чтв 19 Июн 2014 13:03:09 Build Host: brhas6x64.plesk.ru
Group : System Environment/Daemons Source RPM: sw-nginx-1.6.0-1.14051516.rhel6.src.rpm
Size : 726308 License: 2-clause BSD-like license
Signature : (none)
Packager : Parallels <[email protected]>
returns that nginx build by Parallels.

What tests need provide yet?
 
Back
Top