Web Application Security Guide/SSL, TLS and HTTPS basics

SSL/TLS provide encryption and authentication for HTTPS.

For maximum security

• Follow SSLLabs best practices including:
  • Ensure SSLv2 is disabled
  • Generate private keys for certificates yourself, do not let your CA do it
  • Use an appropriate key length (usually 2048 bit in 2013)
  • If possible, disable client-initiated renegotiation
  • Consider to manually limit/set cipher suites

Rationale

SSL is easy to do and hard to do right. SSLLabs provide good guidelines that are updated when new attacks are discovered.

The CA has no need-to-know for your private key. Depending on the cipher suite used, the private key can allow adversaries to decrypt passively eavesdropped communications. Thus, even if you trust the CA, it is better to avoid any risk. Generate a key and a CSR and provide only the CSR to the CA.

Increasing key length increases security, but also significantly increases the CPU load for connection establishment. 1024 bit keys will not be accepted by Mozilla Firefox anymore for certificates that expire after the year 2013. 2048 bit keys should be enough for all applications for quite a few years – using larger key sizes seems to be overkill. (All information based on 2013.) Note: The large CPU overhead of connection establishment can be used by (D)DoS attackers. Such DDoS attacks are harder to detect and defend against when client-initiated renegotiation is supported.

SSL/TLS supports a large set of “cipher suites”, each defining a set of cryptographic mechanisms used to secure the connection. Some of them do provide perfect forward secrecy, some do not. (Perfect forward secrecy means that if the private key becomes available to an attacker, he cannot decrypt data that was eavesdropped before he got the key). Usually, the client (browser) and server choose a cipher suite by first exchanging which suites are mutually supported, and the client’s preferred suite is then chosen. Depending on setup, the server may choose the cipher suite, ignoring the client’s preference. Most defaults are reasonably sane, but for either high-speed or high-security applications, you may want to consider restricting the supported/preferred suites to fast or high-security suites. If you want to exclude clients that do not support sufficient security (e.g. ancient “export control” limited clients), make sure to disable those cipher suites. When configuring cipher suites, carefully check the setup to make sure you do not allow “ADH” suites that do not authenticate the server! If you are unsure, keep the default, and always verify the effects of your settings!