Geekly Articles each Day
📜 ⬆️ ⬇️

How to achieve an A + rating for an SSL certificate on your website, and other aspects of hosting security



In recent years, hosting has turned into a commodity - a full-fledged product, the attractiveness of which is largely determined by the related services. And since information security of websites is of particular importance today, one of the most important aspects of hosting is SSL certificates. All e-commerce somehow goes through hosting, so you need to understand how safe, correctly and conveniently all business transactions are performed. The speaker about Rusonyx at the partner conference "1C-Bitrix" told more about this.

The data released by the Ministry of Internal Affairs of Russia leads to sad reflections:


')
In 2013, the number of cybercrimes - about 11 thousand incidents - amounted to 30% of the total offenses. In 2015, the share of cybercrime increased even more. Hacker attacks are regularly exposed to quite serious projects that we trust our money: first of all, online stores and banks.

Surely, some of you had to set up payment systems in CMS “1C-Bitrix” products. Any payment system forces us to use a secure HTTP connection, SSL certificates. Is it a whim or an effective security measure? To understand this, let's see what an SSL certificate is.

What is an SSL certificate?


An SSL certificate is a cryptographic protocol that protects data transmitted over a network. What tasks is this protocol intended to solve?


How does an SSL certificate work?


When we go to a secure page, the browser sends a request to the server. Among other things, this request passes the session ID. Further, the browser transmits a set of those ciphers with which it can work, and under what protocol. Based on this information, the server decides on which protocol they will communicate in the future, which cipher sets they will encrypt information, and sends the browser a response with its certificate and public key.

The browser checks the certificate: whether it is not withdrawn, not expired, it is convinced of the power of attorney of the certification center that issued it. Next, the browser encrypts the information with a public key and sends it to the server along with the data it needs. Using the private key, the server decrypts the received information. Then both parties to the process in parallel generate symmetric keys, with which they will further encrypt data. As a result, it establishes a secure communication channel through which the server and the browser further exchange information.

What types of SSL certificates are available?


  1. DV SSL (Domain validation). This certificate confirms the domain name. He has a subtype - WildCard. With this subtype, we can protect all subdomains at the same level. For example, either ssl.site.ru or ssl2.ssl.site.ru.

  2. OV SSL (Organization validation). It confirms the domain and organization. That is, when you send a CSR request to a certification center, they check whether an organization really exists with such an TIN, and then they issue you a certificate. He also has a subtype of WildCard.

  3. EV SSL (Extended validation). This certificate confirms the domain name and organization. To receive it, you will have to provide a full package of documents about your organization, that is, an extended check is carried out. Writing this certificate takes longer than other types of certificates, and it costs much more. It does not have a wildcard subtype, but MDC comes to replace it. It allows us to forcefully list the number of domains that will protect this certificate.

  4. UCC SSL. A relatively uncommon type of certificate. Mainly used to protect email services such as Microsoft Exchange Server. At the same time, this certificate allows you to protect up to 100 domains.

  5. Organization ServerSign GlobalIP. Protects all domain names located on the same IP address.

  6. Code Signing Certificate. Used by developers. This certificate can sign the software, that is, it confirms the author of the software, and also guarantees that this product has not changed since the digital signature was applied.

Server testing


Can we be completely sure that the data of our users and clients of the site are safe due to the fact of installing an SSL certificate? To answer this question, let's look at three aspects:


For example, I chose a server on which a number of applications were preinstalled. Front-end —NGINX, back-end — Apache.



The SSL LABS resource is owned by QUALYS, which since 1999 has been involved in cloud protection, so I believe that it can be trusted. Right in the panel, you can install an SSL certificate without interfering with server settings. The rating is pretty bad - “C”. And the first thing I want to draw attention to is that the server still supports the old SSLv3 protocol, vulnerable to a POODLE attack, during which you can intercept and decrypt data. An attacker may intentionally force our client to use the irrelevant vulnerable protocol SSLv3, and use this for his own purposes.

Server optimization


I will give a list of optimizations only for NGINX, Apache should be configured in the same way.

First of all, it would be logical to disable the SSLv3 protocol on the server. This is done in virtual hosts, in server block: in the ssl_protocols directive, we simply remove SSLv3, leaving TLSv1, TLSv1.1 and TLSv1.2. Of course, it will be safer to leave only TLSv1.1 and TLSv1.2, but you may encounter some problems, I will tell about them below.

The second thing that catches our eye when testing is the old cipher suite.



The fact is that older browsers can support cipher suites that are also vulnerable to various attacks. And here is the list of current ciphers:


After we have configured the protocols by which we will work, as well as installed the actual ciphers on the server, it's time to make sure that the client complies with our instructions. To do this, you need to prioritize ciphers by enabling the ssl_prefer_server-ciphers on directive. In this case, when using the SSLv3 and TLS protocols, server ciphers take precedence over client ciphers. This allows you to protect against many attacks such as Logjam, Beast, Freak.

The second, for which SSL LABS did not give us the highest rating, is the use of the weak parameters of the Diffle-Hellman key file.



This key is generated using the openssl dhparam -out , where you need to specify the path to our future key and its length.

 openssl dhparam -out /etc/pki/tls/dh.pem 2048

Many of you may say that you need to use a 4096 key. This is probably safer. But it will slow down the site loading speed. And besides, 2048 is, so far, a fairly safe key length.

The next thing to look out for is the HSTS mechanism. To install the Strict Transport Security header, we need to recompile NGINX along with the HTTP header module.



 add_header Strict-Transport-Security max-age=15768000;

After recompilation we add Strict Transport Security Security header. Thus, we force the client who has come over the HTTP protocol to use the HTTPS protocol. On the one hand, this is good, but on the other hand, it affects SEO optimization. Therefore, before you install this title, it is better to consult with colleagues who are engaged in SEO-optimization of your site.

Further, we see that OCSP Stapling is disabled:



OCSP (Online Certificate Status Protocol) was created to replace the old version of the CRL. Certification centers generated a list of revoked certificates approximately once a week. When the browser connected to our secure server, it downloaded the list of revoked certificates, checked whether our certificate was in it, and if it did not find it, then connected to the site. But this is a rather lengthy procedure, so a faster OCSP protocol was developed. True, he has another drawback, but more on that below.

You can enable Stapling in Server block using directives

 ssl_stapling on; ssl_stapling_verify on;

You also need to specify the path to our root certificate:

 ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

And install the resolver:

 resolver <I DNS resolver>;

Usually they put 8888. This is Google’s public DNS, but if you have your own DNS on the server, then I would recommend to put localhost.

Now about the shortcomings of the OCSP.

The fact is that the revocation certificate verification consists of four stages:




In addition to the fact that we perform unnecessary actions, we also load the certification center itself. Imagine if each client connects to the server and requests personally. To prevent this from happening, we enable OCSP Stapling. This allows the web server to connect to the OCSP Responder itself and download information about whether its certificate has been revoked. This information is cached by the server. Next, we connect only to the DNS, then to the web server and get the data along with the SSL negotiations (handshake).

You can speed up the SSL negotiation process using the SPDY protocol developed by Google. Immediately I warn you that this protocol is unstable, the developer himself said this, but, nevertheless, if you look at the statistics on SSL LABS, many projects use it successfully.

Usually, negotiations consist of three to five stages, and SPDY allows you to do everything in one connection. To enable it, we first have to recompile NGINX, including the spdy module. Next, you need to update OpenSSL to version no less than 1.0.1a. You can enable the protocol itself in the Server block using the Listen directive:

 Listen 443 ssl spdy

The next nuance I would like to draw your attention to is Session Resumption, caching. When we connect to the server for the first time, the client sends the session ID stored on the server. And when we reconnect to it, then if the session ID coincides, it is no longer necessary to perform SSL negotiations, which speeds up the download. You can enable Session Resumption with the following directives:

 ssl_session_cache shared:SSL:50m; ssl_session_timeout 5m;

According to my testing, caching allows you to reduce the average SSL Negotiation value by 10 ms.



Task simplification


Not every one of us has the skills of system administration, so I suggest that all of the above should be forgotten and the task be slightly simplified.

There is a resource like Mozilla SSL Configuration Generator . It is possible with a few clicks to form a ready-made virtual host with the necessary settings, which will allow you to get an A rating in SSL LABS. For example, we select the NGINX web server, the encryption level of modern, that is, the most secure, and indicate the version of the server. After generating our configuration file, we get all the directives that are needed.





Recently, another interesting project appeared - Let's Encrypt . Their certificates protect only the domain name and subdomain. Also, you will not get the green line, about which I spoke - Extended validation certificate, that is, you do not confirm the organization. The authors state that their main goal is to transfer all HTTP traffic to HTTPS by default. In principle, a good idea. I decided to test this service. I downloaded the Python plugin from their website, I installed it for 30 minutes, because it is not yet optimized for many versions of Python. But still I did manage to quickly install the certificate. I received a DV - Domain validation certificate, which confirmed my domain, as well as a subdomain automatically included in my web server.

But there is a faster way.

If your server supports the pre-installed PLESK panel, then in the "Extensions" section you can download and install the Let's Encrypt extension in two clicks. After the introduction of your domain e-mail address, it will be automatically installed on the server. It is important to note that this certificate is issued only for 90 days, and it will need to be updated. This can be done very simply in the PLESK panel by simply pressing the Renew button.

How to achieve the rating of A +?


How, finally, to achieve the rating of "A +"? You need to perform the following optimization:

  1. Disable vulnerable SSL protocols (SSL v1, v2, v3)
  2. Update the cipher suite.
  3. Generate a secure dh_param key.
  4. Enable HSTS mechanism.
  5. Speed ​​up SSL negotiation with OCSP Stapling.
  6. Speed ​​up SSL conversations with SPDY.
  7. Enable caching.

Here is the result of our work:



What should I look for?

After receiving the A + rating, we can see that many old devices and browsers cannot connect to our site, because they simply do not support any cipher suites or protocols.



Therefore, I recommend choosing the encryption level intermediate, rather than modern, in the Mozilla configurator. It will be quite reliable, but you will receive an “A” rating. This is not critical, besides you will not lose potential visitors to your site.

About server security


Installing an SSL certificate on the server does not mean that your clients' data is completely safe. Therefore I would like to give some advice.


The security of your server directly depends on who controls it, and also on you. Otherwise, you can wake up one morning and see something like this on your website:

Source: https://habr.com/ru/post/309536/

More articles:


All Articles