In the previous part, we got to know the theoretical premises to which attention should be paid when preparing for the implementation of SSL / TLS encryption mechanisms. In this part, we will try to focus on the configuration, which guarantees correct presentation of our website to visitors.
2.0 Using complete certificate chains
Once, the Opera browser, when going to a page with an incomplete certificate chain or self-signed certificate, displayed the message: “The chain of certificates for this server is incomplete and the exhibitor is unregistered.” In most of today’s implementations, the server certificate itself is insufficient information for the client. You need two or more certificates to build a complete chain of trust. These certificates are called Intermediate Certificates and are provided by the CA (Certificate Authority). Usually, we can find them for download on dedicated suppliers’ websites; for example, GeoTrust, RapidSSL or Symantec.
An incorrectly uploaded certificate chain incorrectly renders our server’s certificate and displays alerts in browsers. In practice, this problem is sometimes difficult to diagnose because some browsers can display incomplete information, while others do not. All browsers have a tendency to cache and re-use intermediate certificates. If we are not sure whether we have compiled our .pem file with all certificates well, or if the intermediate certificates indicated in the configuration directives are correct, we can check that with the openssl command:
|
1 2 |
openssl verify -verbose -CAfile certyfikaty_posrednie.pem sekurak.pl.crt sekurak.pl.crt: OK |
It is also possible after a test implementation with the What’s My Chain Cert or SSL Checker:
2.1 Using secure encryption protocols
There are currently five protocols in the SSL/TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1 and TLS v1.2 (the TLS 1.3 specification is still polished, but IETF is very close to resolving the final version of this protocol).
- SSL v2 no longer guarantees security and should not be used. It can be used to attack RSA keys and sites with the same name, even if they are on completely different servers. For example, if the mail server supports SSL v2 and the non-attack web server can take advantage of this weakness of the mail server, to terminate TLS connections to the web server (see Decrypting RSA with Obsolete and Weakened eNcryption – DROWN).
- SSL v3 is dangerous when used in HTTP communication (see POODLE attack) and in conjunction with other protocols. It has also been declared outdated and should no longer be used.
- TLS v1.0 (development of SSL v3), although it is outdated and should not be in use, can still be found on the internet. Its main weakness is the Browser Exploit Against SSL/TLS – BEAST attack. Modern versions of browsers have softened its performance, but other problems still remain.
- TLS v1.1 and v1.2 are versions with no major known security problems, but only 1.2 provides modern cryptographic algorithms and authentication of encryption with additional data (Authenticated Encryption with Additional Data – AEAD). Of course, to offer support to older clients, some sites must also support older versions (1.0 / 1.1) of TLS protocols. However, the “retirement” for TLS v1.0 has already been planned by the PCI DSS standard, which will require all parties accepting credit card payments to cease using the version by June 2018.
2.2 Using secure ciphers
Security of communication lies in the certainty that our data exchange takes place directly with the other party and does not pass through someone who will be able to overhear it. In SSL and TLS, these ciphers determine the security of our communication. They are built from various blocks, with the idea of achieving security, thanks to its diversity. If one of these blocks turns out to be weak or dangerous, we should be able to switch to another one. Currently, we should rely primarily on the kits offering the AEAD mechanism that provide strong authentication and key exchange, forward secrecy and encryption of at least 128 bit. As with protocols, some weaker ciphers also need to be handled, but only if they are negotiated only by older versions of clients that do not support anything better. Below are some of the obsolete cryptographic functions that should be avoided:
- All ciphers using anonymous key exchange—Anonymous Diffie-Hellman (ADH) do not provide authentication.
- Sets with weak ciphers (usually 40 and 56 bits) can be easily broken.
- RC4 has already been considered insufficiently safe.
- 3DES is slow and weak.
- All export ciphers; i.e., those that were designed to be sufficiently weak and could be exported from the USA in the 1990s, are dangerous during the negotiation phase of the connection and can also be used against servers that prefer stronger solutions (see: FREAK attack).
- NULL—ciphers that do not use encryption.
ATTENTION! Remember to test all TLS configurations beforehand on dedicated environments. Before all changes are transferred to production, you must ensure that everything works and is in line with our assumptions. It should be remembered that all recommendations are usable in a wide range of applications, but not all systems (especially older ones) support all protocols and ciphers. That is why tests that are carried out in the first place are such an important step in the configuration.
As an entry point, we can use the following set for both types of RSA and ECDSA keys:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 |
The above configuration example uses standard TLS set names. Some platforms and servers may use custom names or abbreviations. Documentation of a given platform should always contain more details about the conventions used.
2.3 Choosing the best client encryption sets
In SSLv3 and later protocols, the client (usually the browser) presents a set of supported ciphers, and the servers select one of them to handle the connection through both sides. Not all servers choose the best—sometimes random sets from the client list are selected. Having servers whose configuration allows you to choose the best from the list is crucial for achieving a better level of security.
2.4 Applying Forward Secrecy
Pass-through confidentiality (sometimes called “Perfect Forward Secrecy”) is a protocol functionality that allows secure communication independent of the server’s private key. When using ciphers that do not support this function, there is a risk that someone who obtains the server’s private key will be able to decrypt all previously overheard and recorded messages. This is another reason to prefer ECDHE kits for current web browsers (support for the older group of clients can be handled by going back to handling also DHE sets).
2.5 Using a strong key exchange
Although RSA key exchanges are still popular, we should avoid this type of operation (of course, this is not always possible). Most of the publicly available key exchange sites already use ciphers from the Diffie-Hellman Ephemeral (DHE) or Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) ciphers using ephemeral keys. Unfortunately, in 2015, a group of researchers published a new attack against DHE, known as Logjam. It was discovered then that the exchange of keys with lower strength (e.g., 768 bits) could be easily broken, and various types of state agencies were able to do this at 1028 bits. Therefore, if we want to be on the safe side by implementing DHE, our configuration should be based on at least 2048 security bits. However, one should consider the fact that some older clients (e.g., Java 6) may not support this level of power. For efficiency reasons, however, we should go towards ECDHE, which is stronger and faster. The ellipse curve secp256r1 (also known as P-256) is a good choice in this case.
2.6 Continuous testing in the laboratory
Where can we find out all these dependencies and choose the best settings when it comes to used servers? The unquestionable leader in the benchmark SSL / TLS settings is the Qualys SSL Labs portal. It offers not only server tests but also used browsers. In this way we can not only check the settings of your server, but also your client’s settings.
There are many ready-made configurations on the Internet that meet the requirements up to the “A” rating level, regardless of whether we use Apache (versions 2.2, 2.4), Nginx, HAproxy, or any other SMTP and FTP servers. I recommend not to use ready-made, but to start the adventure with basic settings and gradually “tweak” the configuration to resolve messages such as “This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B” or “The server does not support Forward Secrecy with the reference browsers” to better understand why the setting is already obsolete and what consequences are associated with leaving it or not adding it to an existing installation. We should work on our configuration until we reach the highest possible level, on which all our assumptions regarding the number and type of clients served will be met. It is also worth to read the BadSSL website and test the list of the most common errors on browsers and the reasons that cause them. With this, we will be able to diagnose problems with our test implementations faster.
To be continued…
In the next part we will look at the subject of performance, which is not always accompanied by a high level of security.