Difference between revisions of "Enhancing SSL Security"

[unchecked revision][unchecked revision]
m (Dweuthen moved page Enhancing Security to Enhancing SSL Security without leaving a redirect)
Line 1: Line 1:
 
+++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++
 
+++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++
  
While setup and configuration of MailStore SPE is just a matter of minutes when sticking to the defaults, additional actions can be taken to enhance the overall security of MailStore Service Provider Edition. These are explained in the following sections.
+
The default configuration of most operating systems allow any set of supported ciphers and hashes to be used by applications when acting as SSL client or server. While this ensures full compatibility with other client and server applications, it does no longer match the expectation in SSL encrypted communication in regards to privacy and trust due to supporting insecure protocols, cipher suites and hash algorithms.
  
== Harding SSL ==
+
Thus enhancing the security of SSL mainly consists of disabling these insecure protocols, ciphers and hashes as well as prioritize cipher suites that allow the usage of [[wikipedia:Perfect Forward Secrecy|Perfect Forward Secrecy]].
Harding SSL consist of mainly of disabling insecure ciphers and hashes as well as prioritize cipher suites that allow the use of [[wikipedia:Perfect Forward Secrecy|Perfect Forward Secrecy]].
 
  
As all components of the MailStore Service Provider Edition rely on the Windows' security support provider (SSP) called ''Secure Channel'' (also known as ''Schannel''), a number of registry keys have to be created or modified to disable insecure ciphers and hashes. Although Microsoft's Technet article [http://support.microsoft.com/kb/245030 How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll] describes in detail which registry keys are responsible for the security provider settings, it is not recommended to manually change these keys. A safer way to adjust the ''Schannel'' settings for server applications is [https://www.nartac.com/ Nartac Software's IIS Crypto] tool.  
+
As all components of the MailStore Service Provider Edition rely on Windows' security support provider (SSP) called ''Secure Channel'' (also known as ''Schannel''), a number of registry keys have to be created or modified in order to disable insecure protocols, ciphers and hashes. Although Microsoft's Technet article [http://support.microsoft.com/kb/245030 How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll] describes in detail which registry keys affect the security provider settings, it is not recommended to manually change these keys. A safer way to adjust the ''Schannel'' settings for server applications is [https://www.nartac.com/ Nartac Software's IIS Crypto] tool.
  
=== Recommended Settings ===
+
== Recommended Settings ==
The highest level of security can be achieved with the following settings in ''IIS Crypto''. Be aware that this will prevent Windows XP clients from connecting. If support for Windows XP is mandatory, use the ''Best Practice'' template of ''IIS Crypto'' which re-enables some weaker ciphers.
+
Highest level of security can be achieved with the following settings in ''IIS Crypto''. In a multi-server setup of MailStore SPE, the changes should be applied to all servers with Management Server or Client Access Server role. P
 +
 
 +
<p class="msnote">'''Please notice:''' The recommended settings will prevent Windows XP clients from connecting to MailStore SPE. If supporting Windows XP clients is mandatory, use the ''Best Practice'' template of ''IIS Crypto'' which re-enables the slightly weaker ''SSL 3.0'' protocol as well as the ''Tripple DES 168/168'' and ''RC4 128/128'' ciphers and ''MD5'' hashes.</p>
  
 
{| class="wikitable"
 
{| class="wikitable"

Revision as of 12:18, 19 September 2014

+++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++ DRAFT +++

The default configuration of most operating systems allow any set of supported ciphers and hashes to be used by applications when acting as SSL client or server. While this ensures full compatibility with other client and server applications, it does no longer match the expectation in SSL encrypted communication in regards to privacy and trust due to supporting insecure protocols, cipher suites and hash algorithms.

Thus enhancing the security of SSL mainly consists of disabling these insecure protocols, ciphers and hashes as well as prioritize cipher suites that allow the usage of Perfect Forward Secrecy.

As all components of the MailStore Service Provider Edition rely on Windows' security support provider (SSP) called Secure Channel (also known as Schannel), a number of registry keys have to be created or modified in order to disable insecure protocols, ciphers and hashes. Although Microsoft's Technet article How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll describes in detail which registry keys affect the security provider settings, it is not recommended to manually change these keys. A safer way to adjust the Schannel settings for server applications is Nartac Software's IIS Crypto tool.

Recommended Settings

Highest level of security can be achieved with the following settings in IIS Crypto. In a multi-server setup of MailStore SPE, the changes should be applied to all servers with Management Server or Client Access Server role. P

Please notice: The recommended settings will prevent Windows XP clients from connecting to MailStore SPE. If supporting Windows XP clients is mandatory, use the Best Practice template of IIS Crypto which re-enables the slightly weaker SSL 3.0 protocol as well as the Tripple DES 168/168 and RC4 128/128 ciphers and MD5 hashes.

Protocols Enabled TLS 1.0
TLS 1.1
TLS 1.2
Ciphers Enabled AES 128/128
AES 256/256
Hashes Enabled SHA
Key Exchange Enabled Diffie-Hellman
PKCS
SSL Cipher Suite Order TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA