SSL/TLS Best Practices
Network traffic is protected, isn't that enough?
Today, more than half of online traffic is already encrypted. This is a good trend, but simply adding encryption to a web page is not the ultimate solution. Decryption of SSL/TLS requires a lot of machine power, and its success is still not certain. It is much easier for cybercriminals to find a security hole on your server and exploit it. Once the server has been accessed, it is possible to capture the Private Key of the certificate, in which case the encryption itself has also been broken.
There are many different server platforms. Popular web server platforms include, for example Apache, NGINX and IIS.
If your server was acquired through a service provider, it is likely that it has a reasonable level of protection. This naturally depends on how active your service provider is. You can check the security of your own server with SSL Server Test (SSL Labs) .
If the information opened via the above-mentioned link does not tell you anything, you should turn to the experts. Contact us if we can't help, we know how to guide you in the right direction and save you time. We know how to use SSL/TLS certificates, but we don't even try to embrace the whole security world because that would break our focus: The best service in SSL/TLS certificates.
RSA- or ECC-key?
For most services and sites, the protection offered by 2048-bit RSA keys is sufficient. The public key RSA algorithm is widely supported, making this type of key a secure default option. 2048-bit keys provide about 112 bits of protection. When aiming for stronger protection, it should be noted that RSA keys do not scale very well. For example, to get 128-bit security, you need a 3,072-bit RSA key, which is significantly slower. The alternative is ECC (Elliptic Curve Cryptography) keys, which offer better protection and performance. A 256-bit ECC key provides 128-bit protection. Some of the older clients do not support ECC, but modern clients do not have this problem.
Protect the Private key
Handle the Private Key carefully, access to it should be limited to the smallest possible number of people within the limits of practicality.
The Private Key must be generated securely in a trusted/protected environment and protected with a password if they are saved as separate files. There is also separate hardware (Hardware Security Module/HSM) with which the keys can be kept protected. However, these are expensive and often only used by larger organizations.
If there is reason to suspect that the Private Key has been compromised, revoke the certificates and create new keys.
Certificates must be renewed on time and often enough. According to current regulations, the lifetime of the most public SSL/TLS certificates is a maximum of about one year. When renewing a certificate, new keys should also be created, unless there is a compelling reason to use the same keys.
Hostname coverage
Make sure the certificate covers all the addresses/hostnames you want to use on your service or site. This way, you avoid the resulting error messages that confuse users and cause mistrust.
In most cases, you should also make sure that the certificate works for service addresses both with and without the www prefix (example.com / www.example.com). As a good rule, a secure web server should have a certificate that is valid for every DNS name configured to point to it.
Add all necessary domains to the Subject Alternative Name (SAN) of the certificate, as not all modern browsers check the Common Name of the certificate for validation.
Choose a trusted CA
Certificate producers are regularly audited, but some CAs take data security more seriously than others. Choosing the best option is not necessarily easy, but one way is to look at the history of the CA, and more importantly, how it has responded to the problems it has faced and learned from its mistakes.
At a minimum, the CA should provide support for both Certificate Revocation Listing (CRL) and Online Certificate Status Protocol (OCSP) for optimal performance.
All CAs offer domain validated (DV) certificates. In addition, it is worth checking whether the certificate producer has support for certificates produced with both the RSA and ECDSA key algorithms. Due to its performance advantages, ECDSA may become a more viable option in the future.
The usability of the certificate management environment varies with different certificate providers. Especially in cases where a large number of certificates are needed, it is good to choose a CA that offers good tools for managing certificates.
Choose a CA that also offers technical support related to its products.
SHA (Secure Hash Algorithm)
The security level of the certificate is affected by the strength of both the private key used to sign it and the hashing algorithm (SHA/Secure Hash Algorithm). In the past, certificates used the SHA1 algorithm, which is now considered insecure due to vulnerabilities that appeared in it.
As a result, there has been a shift to using the SHA2 algorithm, and vigilant CAs have not delivered certificates signed with the SHA1 algorithm since 2016.
DNS CAA Record
With the help of the DNS CAA record, domain owners can, if necessary, limit which certificate providers can issue certificates for that domain. If the record is not defined or is empty, there is also no limit. If the CA has an automated process for issuing certificates, it should check the DNS CAA records. This reduces improper issuance of certificates. English instructions for adding the CAA label can be found here.
There are also tools for checking the CAA record from several different sources, here you can find Entrust's.
Mixed Content issue
The browser warns that your site is not secure. A more detailed description reveals that the site has so-called Mixed Content problem. The link in the content leads to another html page, which does not use https traffic but is an http link. Below are possible solutions for configuring the server.
Lähde: badssl.com
HTTP Strict Transport Security (HSTS)
This method prevents a situation where a cybercriminal has access to the traffic between the user and the website, i.e. the so-called man-in-the-middle (MITM) attack. The background for this is that if you go to the website by entering, for example, only the domain name: ssl-apua.fi into the browser, the first request that comes to the server is always unencrypted. Or, if you go to the page with the link https://ssl-apua.fi - the same thing. The HSTS setting on the server tries to force all traffic to be encrypted, i.e. instructs the browser that the website must be accessed via https traffic.
Content Security Policy (CSP)
In order to access a reasonably secure web service, this setting should be enabled in addition to the above. This blocks the possibility of using insecure (http) links by third parties, i.e. that one of your partners or other external parties adds a link to their own pages and links information from your pages there. The Content Security Policy forces this traffic to be encrypted as well. More information and configuration instructions on Mozilla's page behind this link.
Obsolete or retired Cipher Suites
The cipher suite defined for the server (usually there are several of these) determines how the connection between the browser and the server is authenticated and which encryption method is used. Cipher Suites include, for example, TLS 1.0 - 1.2 and the latest TLS 1.3.
Use only valid, secure Cipher Suites on the server.
There are six SSL/TLS protocols: SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2 and TLS v1.3. SSL v2 and SSL v3 protocols are already deprecated and should not be used. In March 2021, the IETF (The Internet Engineering Task Force) issued a publication stating that the TLS 1.0 and TLS 1.1 protocols have also been formally deprecated. With this, the use of these is no longer recommended, although some browsers have already denied support for them in the past (Chrome, Firefox, Internet Explorer).
Lähde: badssl.com
PEN testing servers or applications
PEN-Testing is friendly hacking that is carried out as planned and with permission. Experts specializing in testing try to find vulnerabilities in your service in pre-agreed ways. The goal is to find flaws in the service that could enable a hostile attack or data breach on the target. The result of PEN testing is a report on the findings and even suggestions for corrections.
PEN testing is a safe way to find out the possible vulnerability of services. PEN testing is also offered in our country by, for example, some specialized IT companies.
The recommended way to do PEN testing is to align it with the test environment. PEN testing can be very intrusive and even though the purpose is not to break the target system, it can cause data corruption and service breakdown. Although PEN testing is a deep probe into the service's weaknesses, vulnerabilities may remain in its wake.
Almost all systems can contain vulnerabilities that are time-consuming to find. Sometimes you can't even fix them on your own. Vulnerabilities are often found in some third-party component that can only be affected by the author of the component.