I am working on changing the encryption specifications on several web servers that I manage to avoid the BEAST / BREACH / CRIME curvature that everyone is talking about.
On our LAMP hosts, I just upgraded to OpenSSL 1.0.1 and Apache 2.4 and used these encryption specifications:
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384: ECDHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384: ECDH-RSA-AES256-GCM-SHA384: AES256-GCM-SHA384: AES256-GCM-SHA384: AES25H-GCM-SHA384: - RC4-SHA384: ECDHE-RSA-RC4-SHA: AES256-GCM-SHA256: RC4-SHA: ECDHE-RSA-AES256-SHA384: ECDHE-RSA-AES128-SHA256: DHE-RSA-AES256-SHA: DAY - CAMELLIA256-SHA: AES256-SHA256: AES256-SHA128: AES128-SHA128: AES256-SHA: AES128-SHA: MD5: NULL
What function do I want - compatible clients usually get the encryption specification from this topic, and I hope that in the future TLS 1.2 compatible clients will receive GCM packets, and it's not so elegant. However, we have very important ASP.NET applications running in IIS 7.5 on Server 2008 R2 (fully patched), and the "SSL Cipher Suite Order" group policy does not seem to support this.
In Server 2008 R2, Group Policy for Cipher suites lists supported ciphers. Apparently, it only supports GCM ciphers for ECDHE_ECDSA , not ECDHE_RSA . For ECDHE_RSA , only CBC is supported. In addition, there is no support for combining ECDHE_RSA with RC4.
Am I missing something, or is there a good workaround? All I can do is proxy through a host that supports the encryption I want, but this is undesirable for a number of reasons. Am I stuck using a regular RSA-RC4-128-SHA ? Or, if I turn off HTTP / TLS compression and take off performance, can I use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 or the like is safe?
Sorry if that doesn't make much sense, I'm pretty new to this.
source share