How to achieve an A + rating for an SSL certificate on your website, and other aspects of hosting security / 1C-Bitrix Blog

In recent years, hosting has become a commodity - a full-fledged product, the attractiveness of which is largely determined by related services. And since the information security of websites is of particular importance today, SSL certificates are one of the most important aspects of hosting. All e-commerce somehow passes through the hosting, so you need to understand how safely, correctly and conveniently all business operations are performed. The speaker of the Rusonyx company at the partner conference “1C-Bitrix” spoke in more detail about this .

The data released by the Ministry of Internal Affairs of Russia suggest sad thoughts:



In 2013, the number of cybercrimes - about 11 thousand incidents - amounted to 30% of the total amount of offenses. In 2015, the proportion of cybercrime has grown even more. Quite serious projects are regularly exposed to hacker attacks, to which we trust our money: in the first place, online stores and banks.

Surely, some of you had to set up payment systems in the 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 figure this out, let's see what an SSL certificate is.

What is an SSL certificate?

SSL certificate is a cryptographic protocol that protects data transmitted over the network. What are the objectives of this protocol?

• Transmitted data must be confidential. Users and customers do not want their usernames, passwords, e-mail addresses, bank accounts and credit card numbers to be scattered across the network.
  
  
• Even if the data is intercepted during an online transaction, it should remain untouchable. An attacker should not be able to use the data for their own purposes, or to change them.
  
  
• Any self-respecting organization should make sure that the client is confident in the reliability of the data about the organization, about their legal purity.
  
  
• And the last important fact is the implementation of national and international regulations on the protection of information. This is especially true for those organizations that plan to bring their online business to the world market.

How SSL Certificate Works

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

The browser checks the certificate: whether it has been revoked or expired, it is convinced of the power of attorney of the certification center that issued it. Next, the browser encrypts the information with the public key and transfers it to the server along with the data it needs. Using the private key, the server decrypts the received information. Then both participants in the process simultaneously generate symmetric keys, with the help of which they will subsequently encrypt the data. As a result, it establishes a secure communication channel through which the server and browser subsequently exchange information.

What are the types of SSL certificates?

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). He confirms the domain and organization. That is, when you send a CSR request to a certification center, they check to see if there really exists an organization with such a TIN, and then they issue you a certificate. It also has a subtype of WildCard.
   
   
3. EV SSL (Extended validation). This certificate confirms the domain name and organization. To receive it, you have to provide a full package of documents about your organization, that is, an extended check is carried out. It takes longer to issue this certificate than other types of certificates, and it costs a lot more. It does not have a WildCard subtype, but it is replaced by MDC. It allows us to enforce the enumeration of the number of domains that this certificate will protect.
   
   
4. UCC SSL. A relatively rare type of certificate. It is mainly used to protect mail services such as Microsoft Exchange Server. Moreover, 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. With this certificate you can sign software, that is, it confirms the author of the software, and also ensures 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 site customers are safe due to the mere fact of installing an SSL certificate? To answer this question, let's look at three aspects:

• SSL Testing Methods.
• Testing a third-party server using SSL LABS.
• Server optimization.

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



The SSL LABS resource belongs to QUALYS, which has been engaged in cloud protection since 1999, so I believe that it can be trusted. You can install an SSL certificate directly in the panel, without any intervention in the server settings. The rating is pretty bad - “C”. And the first thing I want to pay attention to is that the server still supports the old SSLv3 protocol, which is vulnerable to a POODLE attack, during which it is possible to intercept and decrypt data. An attacker can intentionally force our client to use an irrelevant vulnerable SSLv3 protocol, and take advantage of it for their own purposes.

Server optimization

I will provide a list of optimizations for NGINX only; you need to configure Apache in approximately the same way.

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

The second thing that catches our eye when testing is an old set of ciphers.



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

• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSAAES128-GCM-SHA256
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHEECDSA-AES256-GCM-SHA384
• DHE-RSA-AES128-GCM-SHA256
• DHEDSS-AES128-GCM-SHA256
• kEDH + AESGCM
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA
• ECDHE-ECDSA-AES128-SHA
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• ECDHE-ECDSA-AES256-SHA
• DHE-RSA-AES128-SHA256
• DHE-RSAAES128-SHA
• DHE-DSS-AES128-SHA256
• DHE-RSA-AES256-SHA256
• DHE-DSS-AES256-SHA
• DHE-RSA-AES256-SHA
• aNULL
• eNULL
• EXPORT
• DES
• RC4
• 3DES
• MD5
• PSK

After we have set up the protocols by which we will work, and also installed the current ciphers on the server, it is time to make sure that the client clearly follows our instructions. To do this, ciphers must be prioritized by including the directive ssl_prefer_server-ciphers on. In this case, when using the SSLv3 and TLS protocols, server ciphers are more priority than client ones. This allows you to protect yourself from many attacks such as Logjam, Beast, Freak.

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



This key is generated using the command 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 must use a 4096 key. Perhaps this is safer. But it will slow down the site loading speed. And besides, 2048 is, for now, a pretty safe key length.

The next thing you need to pay attention to is the HSTS mechanism. To set 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 recompiling, we add the Strict Transport Security header. Thus, we force the client that has entered over the HTTP protocol to use the HTTPS protocol. On the one hand, this is good, but on the other, it affects SEO optimization. Therefore, before setting this heading, it is better to consult with colleagues who are engaged in SEO-optimization of your site.

Next, we see that we have disabled OCSP Stapling:



OCSP (Online Certificate Status Protocol) was created to replace the old version of CRL. Approval centers approximately once a week generate a list of revoked certificates. When the browser connected to our secure server, it downloaded the list of revoked certificates, checked if it contained our certificate, and if it didn’t find it, it connected to the site. But this is a rather lengthy procedure, so the 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 must also specify the path to our root certificate:

ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

And install resolver:

resolver ;

They usually put 8888. This is the Google public DNS, but if you have your own DNS on the server, then I would recommend setting localhost.

Now about the disadvantages of OCSP itself.

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

• connect to DNS to get the IP address of the web server,
• connect to the web server
• we get a certificate
• to check whether it is revoked or not, we reconnect to the DNS, get the IP address of the certification center, and then we get the status.

In addition to performing unnecessary actions, we also load the certification center itself. Imagine if each client connects to the server and requests in person. To prevent this from happening, we include OCSP Stapling. This allows the web server to connect to the OCSP Responder itself and download information about whether its certificate has been revoked. The server caches this information at home. Next, we connect only to DNS, then to the web server and receive data along with SSL negotiations (handshake).

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

Typically, 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 by enabling the spdy module. Next, you will need to update OpenSSL to version at least 1.0.1a. You can enable the protocol itself in Server block using the Listen directive:

Listen 443 ssl spdy

The next nuance that I would like to draw your attention to is Session Resumption, caching. When we connect to the server for the first time, the client passes the session ID stored on the server. And when we reconnect to it, then when the session ID matches, SSL negotiations are no longer required, 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 can reduce the average SSL Negotiation by 10ms.

Task simplification

Not all of us have system administration skills, so I suggest that you forget all of the above and simplify the task a bit.

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





Another interesting project has recently appeared - Let's Encrypt. Their certificates protect only the domain name and subdomain. Also, you will not receive the green line that I spoke about - Extended validation certificate, that is, you do not confirm the organization. The authors claim that their main goal is to translate all HTTP traffic by default into HTTPS. In principle, a good idea. I decided to test this service. I downloaded the Python plugin from their site, installed it for about 30 minutes, because it has not yet been optimized for many versions of Python. But still, I really managed to install the certificate pretty quickly. 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 entering 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 clicking the Renew button.

How to achieve an A + rating?

How, in the end, how to achieve the rating “A +”? You need to perform the following optimization:

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

Here is the result of our work:



What should I look for?

After receiving an “A +” rating, we can see that many old devices and browsers cannot connect to our site, because they simply do not support any sets of ciphers or protocols.



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

About server security

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

• Delineate your services across different VPS servers. By the way, 1C-Bitrix at least knows how to deploy a web cluster out of the box. Technical support example: customers often report spam problems. Either they were spammed, or they received a vulnerability on the site and they downloaded a spamming script. As a result, either inode or disk space gets clogged with the client. But in essence, this is not a problem of spam, but the inoperability of the site itself, when input-output operations cannot be performed elementarily. The site is down, the database is down.
• Always put down the correct rights to files and directories. In the directory - 755 to files - 644. Fortunately, 1C-Bitrix can do this by default too. Never leave files without group users; attackers can also take advantage of this.
• Do not put passwords that are easy to understand for a person that are amenable to selection.
• Limit access to port 22, as well as to other IPtables ports, that is, to the server firewall.
• Also, I would advise you to disable and not use FTP, it is better to switch to SFTP.
• Give up telnet, use SSH.

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