SSL / TLS is a seemingly simple technique that ensures, among other things, protection of data. It guarantees the confidentiality of data transmission over the internet, while maintaining the simplicity of installation and operation—apart from situations when it is not. At the end of 2014, the giant from Mountain View, Google, reported that sites using SSL certificates will be more “liked” in the search results, as well as more willingly indexed.
Google wants to introduce websites into the next stage of secure internet. Already at the beginning of 2017, Chrome got mechanisms that when connecting to any website had unambiguously answered the user’s question: Can I use it securely?
Finally, Google is not just about security but also the quality and speed of communication. Implementing HTTPS is only one step away from implementing HTTP 2.0; i.e., gaining several new functionalities when transmitting Internet applications. Like any change, it has its advocates and opponents. The fact is that the biggest players set standards, and others follow them. All these signs indicate that the era of “pure” communication is ending, and the domination of the “cipher” begins. Therefore, if we are to enter into encryption combined with performance—which is often not easy to implement correctly—I want to introduce administrators and programmers to what additional effort should be devoted to configuring their servers and applications.
1. Keys and certificates
In the T)ransport L)ayer S)ecurity mechanism, security starts with the cryptographic identity of the server. At the beginning, we need a strong private key to stop outsiders from attacking us and our clients. The second important factor is the current (temporary) and strong certificate that grants the right to our key to represent our server or domain. Without these two basic pillars, we are not able to build a secure communication tunnel.
1.1 Private 2048-bit keys
In 2005, the US National Institute of Standards and Technology (NIST) issued the first revision of the “NIST Special Publication 800-57 – Recommendation for Key Management”, which suggested that 1024-bit RSA keys would not be usable after the year 2010. Therefore, you should go for 2048-bit keys, which should be valid until the year 2030. Some websites use 4096-bit keys, believing that “more is better.” However, this saying does not always coincide with the truth, because the longer the key, the more computing and memory resources it requires (more energy is used, too). For most websites, the security provided by 2048-bit RSA keys should be sufficient. The RSA public key algorithm is widely supported, which means that for now, these types of keys are a safe, default choice. At 2048 bits, we have 112 security bits.
If you want to provide a greater level of security than this number, remember that RSA keys are not the best choice for scaling. To obtain 128 bits of security, you need a 3072-bit RSA key, which is much slower. ECDSA keys are a good alternative that offers greater security and performance. According to ENCRYPT II, the 256-bit elliptical curve key offers the same level of security as the 3248-bit asymmetrical key and allows much more operations to be performed, saving many CPU cycles and thus the ability to handle more customers. In fact, only a small number of older clients do not support ECC (Elliptic Curve Cryptography), but if we want to keep a balanced world and do not mind the amount of configuration, we can implement support for both RSA and ECDSA keys.
1.2 Protection of private keys
While protecting and handling private keys, one should consider several principles that we can follow:
- Keys should be treated as passwords for administrative accounts. Only a limited group of employees should have access to them, which is directly related to the process of generating and uploading them to specific systems and devices.
- Key generation should take place on trusted machines that have the appropriate level of entropy. Some certification authorities offer to generate private keys for us—you should beware of these types of solutions, because it is not a fully transparent process for us. We cannot control it or even have an insight at every step.
- Although the passwords do not protect production systems from obtaining decrypted keys from the process memory by very experienced attackers (unless we use hardware security modules), they should be used to prevent their private keys leakage; e.g., by compromising the backup system.
- After the leakage of any of our encryption components, you should immediately invalidate old certificates and keys and generate completely new ones.
- Renewing certificates should take place on an annual basis, or if we have the technological capabilities (in the form of process automation; more on this later) and the financial resources—more often. Why? First, certificates with shorter life cycles are more secure in practice (break time is much longer than certificate lifetime). Second, continuous development of technology and research on cryptography makes this process dynamic. Encryption algorithms used to build TLS this year may be broken and considered dangerous in the future. Therefore, longer cycles can only be a waste of time and money.
- Every time you renew the certificate—even if there is no attack or leak—use new keys—unless you use the Public Key Pinning mechanism. However, in this case we also have the ability to determine the validity of the public key and define its backup version, so we can rip these activities over time.
When planning the implementation of encrypted communication, we must make a list of all domain names to which we want to provide a certificate. The worst thing that can happen on the part of our user is the browser’s warning that the certificate for the selected page is incorrect. The confusion of users and the weakening of their trust in such a situation is more than likely. Even if we only want to use SSL for one domain, we must remember that there is chaos on the Internet today regarding the recognition of www as part of the address or subdomain. Therefore, we are unable to control from which version of our address the user will reach us. In most cases, this problem is solved by one certificate providing protection for the domain—with and without the prefix www (domena.pl / www.domena.pl); e.g., using the Subject Alternative Name. The iron rule of having a secure web server is to have an SSL certificate for each domain that points to it with the appropriate DNS records.
Of course, there are also wildcard certificates (*.domain.pl), covering all subdomains to the first dot “.” On the right. In this case, you should also be careful about providing keys to this type of certificate, especially if it means access for a larger group of people from other teams or departments (even within the same company). In such cases, it is worth considering giving up such a solution to several individual subdomains. In other words, the less people have access to the encryption backlog, the better. It is important to realize that sharing certificates also creates a danger bond. A vulnerability in one web site, server or application affects all other sites and servers that use the same certificate.
1.4 Obtaining certificates from reliable Certification Authorities (CA)
When selecting Certification Authorities, we have to be guided by several premises. Sometimes in the history of the Internet, different CAs were thrown out of top browsers and their products revoked. It is best then, before the choice, to get to know the history and reputation of the center to make sure that it treats its activities seriously on the market of security certificates. First of all, before making a decision, it is worth knowing about:
- The CA’s demeanor to security. All centers are subject to regular audits, but some are more serious and rigorous than others. By browsing the history of reviews and articles on the Internet about a given company, you can come across different mentions of various incidents, reactions to them, and whether the company has learned from its own mistakes.
- Focusing on a specific activity. Companies whose main activity orbits only around certificates, have much to lose if they neglect the standards they set previously. That is why it is worth choosing companies that are focused on providing specific services related to Internet traffic encryption.
- If we are talking about services, then surely offices should have CRL – Certificate Revocation List, which is a list of revoked certificates and OCSP – Online Certificate Status Protocol, which are methods supporting the cancellation and checking the status of individual certificates. The standard should be high performance and availability of such services—which is great if they have a dedicated website that informs about the availability of individual subpages and services. If we plan to manage a large number of certificates, we naturally also need to emphasize the availability of tools that will make it easier for us to manage them.
The security of the certificate depends on the power of the private key that was used to sign the certificate and the strength of the hash function used to digitally sign the data contained in the certificate. Until recently, most certificates were based on the SHA-1 function.
Due to its ever weaker encryption power, in the era of computing power of today’s computers, it was considered dangerous and the process of migration to SHA-2 (256) began. The good news is that from January 2016, we should no longer receive a SHA-1 signed certificate from any CA, and according to the declaration of Microsoft, Mozilla and Google, from January 1, 2017, all SSL certificates signed with this algorithm were not going to be supported in the products of these companies.
To be continued…
In the next part, we will take care of the correct configuration of the server-side TLS to ensure that our data is presented to customers through secure cryptographic ciphers and that all known weaknesses are excluded from this communication.