Transport Layer Security (TLS), the successor protocol to Secure Sockets Layer (SSL), is the standard security technology for establishing an encrypted link between two systems, such as a web server and a browser, to prevent third parties from reading or modifying transferred information, including personal details. The encryption algorithms used in TLS/SSL scrambles data in transit, making it very difficult to read while it is being sent.
Of all the findings Alcorn Group raises, weak TLS/SSL configuration is one of the most frequent. Using insecure protocols or weak cryptography undermines the intent of the security measures in place and leaves data accessible to prying eyes.
In this blog post, we are shining a light on our preferred practices.
There are currently six protocols in the SSL/TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2, and TLS v1.3. Published in August of 2018 (RFC 8446), the latest encryption protocol, TLS v1.3, was released with a redefined handshake protocol which simultaneously speeds up communication and protects downgrade attacks. However, since its release a group of researchers have successfully performed a downgrade attack on TLS v1.3 when RSA ciphers are in use.
Although there is a known vulnerability, at the time of writing, TLS v1.3 is the best protocol to use as it significantly reduces attack vectors compared to previous versions. Crucially, it also removes obsolete features from TLS v1.2, including SHA-1, RC4, DES, 3DES, AES-CBC, MD5, Arbitrary Diffie-Hellman groups, and EXPORT-strength ciphers. Cipher suites are defined differently to previous versions and do not specify the certificate type or the key exchange mechanism. Due to its recency, it is not yet supported on all browsers.
TLS v1.2 and TLS v1.3 support Authenticated Encryption with Associated Data (AEAD). This encryption provides simultaneous assurances on confidentiality, integrity and authenticity of the data. Therefore, when deploying servers, TLS v1.3 should be the default protocol, with TLS v1.2 the next preference. There may be a valid business case for use of TLS v1.0 and TLS v1.1 to support older browsers, however, this is sacrificing security for compatibility. It is best to disable support for the deprecated protocols SSL v2 and SSL v3 as these protocols have high levels of insecurity and are vulnerable to Person-in-the-Middle (PitM) attacks.
Where it becomes necessary to support older protocols like TLS v1.0 or SSL v3, consider using TLS_FALLBACK_SCSV. This mode can prevent protocol downgrades from being forced by MitM attackers. Alternatively, specify all protocols that your application is willing to accept.
Certificates should always be obtained from a reliable Certificate Authority (CA). When making the purchasing decision, perform research on how the certificate authority responds to public breaches, as well as how many breaches have occurred. Also important are the services offered. Certificate Authorities should provide a Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) revocation methods.
Your certificate needs to be properly validated against its hostname. If the Common Name (CN) of the certificate is different from the hostname, it becomes more difficult for users to verify the authenticity and identity of the web server. A mismatched certificate nullifies the use of SSL, and an attacker could then establish a Person-in-the-Middle attack against the remote host without changing the user experience.
Of particular note should be the cryptographic algorithms your certificate employs. A certificate will use two pieces of encryption which work hand in hand: the hashing algorithm and the signing algorithm.
Ensure your certificates are hashed with a minimum algorithmic strength of SHA-256 and signed with a minimum* key length of 128-bits in length (symmetric / shared key crypto), or 1024-bits in length for use in key exchange (asymmetric / public key crypto). Currently, the recommended hashing algorithm for a digital certificate is SHA256, with an RSA signing algorithm of a key length of at least 2048 bits.
Bigger is better when it comes to key length and security. However, overly large key lengths will take more power to process.
Further reading can be found here: