SSL/TLS implementation used by Windows Server supports a number of cipher suites. Some of them are more secure in comparison to others. Fortunately, there is a way to explicitly specify the set of cipher suites the server is permitted to use in order of preference.
Thanks to such a capability, it’s possible to configure the server to use key agreement methods that provide a perfect forward secrecy. Perfect forward Secrecy (PFS) is an attribute of Diffie-Hellman and Elliptic Curve Diffie-Hellman key agreement methods in Ephemeral mode (DHE and ECDHE respectively).
Security enhancement provided by PFS is the following:
If the server private key is being compromised, this does not give an attacker a chance to decrypt sniffed sessions. This is because with DHE or ECDHE key agreement the server public/private key pair does not participate in encipherment/decipherment processes, but in digital signing and signature verification only.
RSA key exchange does not provide PFS, since with RSA key exchange the public/private key pair is used for encipherment/decipherment of a pre-master secret that a client sends to the server during a handshake. If RSA private key is being compromised, it’s possible to decrypt pre-master secrets of sniffed sessions and subsequently, sessions themselves.
If you would like to configure the server to accept secure connections with PFS only, it’s required to select cipher suites that imply DHE or ECDHE as a key agreement method.
This field is a whitelist of ciphers your server is permitted to use for SSL/TLS handshake in order of server preference. You can keep from disabling weak ciphers in registry, specifying the ciphers you like in this field.
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
Please keep in mind that this set of cipher suites is only applicable for certificates with RSA public / private key pair.
Note that the first cipher in the list will be marked as "weak" in SSL labs and it will reduce the mark to B, because Windows Server uses weak (1024bit) DH parameters for DHE key exchange. However, thanks to this particular cipher Google Chrome doesn't treat the connection as obsolete.
Regretfully, there is no way to change DH parameters size in case of Windows Server: Windows Server 2012 R2 added TLS_DHE_RSA > 1... | Qualys Community
Another benefit - this cipher suite provides compatibility with clients that do not support Elliptic Curve Cryptography (ECC).
With the set of cipher suites as in the example above, you get B mark in SSL labs:
But Google Chrome reports that the connection is secured with modern cryptography:
If A mark in SSL labs is critical for you, you should consider excluding the first cipher suite (TLS_DHE_RSA_WITH_AES_128_GCM_SHA256) that imply DHE key exchange leaving cipher suites with ECDHE key exchange only:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
With this set of ciphers you get “A” from SSL labs:
But Google Chrome treats SSL/TLS configuration as obsolete:
In case of RSA keys, there is no compromise solution unfortunately. It will be though, as soon as Microsoft adds support for TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite to SChannel or makes Diffie-Hellman parameters configurable by a server administrator. We would recommend checking security updates for SChannel to timely update configuration once one of the aforementioned solutions becomes available.
Cipher suites should be entered as a single line with a comma as a separator. Refer to the syntax in the example above.
Once the required ciphers are entered, click Apply >> OK.
Need help? We're always here for you.