Experience of implementing "Continent TLS VPN" in a cluster configuration
Hi, Habr! We were faced with the task of introducing the product of the Security Code company Continent TLS VPN. In this article, we share our experience in the implementation of this product.
TLS is a cryptographic protocol that provides secure data transfer between nodes on the Internet. You can read it here or here .
TLS key tasks:
This protocol is widely used in applications that work with the Internet, such as web browsers, e-mail, instant messaging and IP telephony (VoIP).
')
In our case, it was necessary to provide secure access to a web resource using GOST encryption.
Requirements:
Below is a diagram and description of the components.
To solve this problem, the Security Code product “Continent TLS VPN” was selected, which meets all the above conditions.
It is worth noting that at the time of design it was the only certified PAC performing encryption according to GOST using the TLS protocol. In the future, it is expected to receive the ViPNet TLS PAK certificate from InfoTeX.
The main elements of the system:
SKZI "Continent TLS VPN Client" - a TLS client is a software installed on a computer of a remote user, which functions in conjunction with a TLS server. TLS-client is designed to implement secure access of remote users to the web resources of the corporate network through communication channels of common data networks.
NetScaler is an application delivery controller that provides flexible service delivery for traditional, container, and microservice applications from a data center or any cloud. Citrix Netscaler based balancer scatters HTTPS sessions between TLS server clusters. Answers from the WEB server also collects balancer.
SKZI "Continent TLS VPN Server" - the server is designed to provide secure access for remote users to protected resources.
The first difficulty arose when running TLS-servers. The message “No controller found” has appeared. Together with the specialists of Security Code, a rather non-standard problem was identified. It turned out that the PAC refused to work in the data center with BenQ monitors, and worked with any others without problems.
The initial setup is simple and consists mainly of the definition of the ip-address and gateway, as well as the name of the device. Plus creation, export / import of a master key.
The customer in the project used two TLS servers. Both TLS servers must be active-active.
A master key is created on one server, and imported to other servers. The master key (cluster key) is designed for the following tasks:
When exporting the master key, the TLS server received only a single USB flash drive from Transcend 3.0 4GB. No flash drives, even those that came bundled with the Security Code, unfortunately, did not fit.
Next, you need to connect to the TLS server on the web face, define the protected resource and install certificates for server operation (CA root certificate, server certificate, certificate for remote server management, administrator certificate and CRL). All these certificates must be issued by one CA. For the first connection on the web-face, you need to use CryptoPro CSP, and not “CSP Security Code. In subsequent changes of certificates, it is better to first delete the root certificate of the CA, and then change other certificates.
Due to the inability to immediately make the combat certificates, it was decided to test the operation of the TLS server cluster on the certificates made on the Krypto Pro test center.
On TLS servers, it is possible to disable user authentication. In this case, a secure channel will be created if you have a TLS client and installed certificates (root, server certificate and CRL), i.e. personal certificate for work is not required.
Initially, there were problems with connecting via a secure channel to a protected resource using the certified version of the TLS client from the Security Code. It turned out to connect to the protected resource using the TLS-client 2.0 from the Security Code, but this version is still at the certification stage. The problem was the wrong redirect on the protected resource, which did not pass, because the TLS servers did not quite correctly work out this rule in the release version of the firmware. To solve the problem, it was necessary to reflash both TLS servers and lift backups made.
The order of flashing is as follows:
To enter debug mode on the TLS server, you must press the F2 key.
For version 1.2 file / usr / share / tls / webmgr / templates / websrv / nginx / base
Remove the proxy_redirect line from it and recalculate the checksums.
After the operations performed, a certified TLS-client from the "Security Code" earned, which the customer insisted on working in the system. But here’s the trick, it didn’t work in the Chrome browser, the work in which was just necessary for the customer, one could even say that everything was honed under it. A number of tests were conducted in conjunction with the support of the Security Code, and, as a result, everything worked on a slightly newer version (1.2.1073) than the certified version (1.2.1068).
By the way, one more of the pitfalls when setting up any TLS client from the Security Code (except for version 2.0) - they do not work on virtual machines. During testing, virtual machines were often used, which complicated the diagnostic process a little more.
In the end I would like to summarize. The product is easy to configure and deploy. There is still something to work with developers, this applies to both the server and the client. But in general, the product is working and works in a cluster configuration. The system is currently running without failures and keeps the load. We hope that our stuffed bumps will help you deploy TLS Continent faster and more efficiently.
Article prepared by Ilya Platonov.
Introduction
TLS is a cryptographic protocol that provides secure data transfer between nodes on the Internet. You can read it here or here .
TLS key tasks:
- ensure confidentiality, that is, implement protection against leaks of transmitted information;
- to ensure the detection of a substitution, that is, to implement the preservation of the integrity of the transmitted information;
- provide authentication of nodes, that is, give a mechanism for authenticating the source of messages.
This protocol is widely used in applications that work with the Internet, such as web browsers, e-mail, instant messaging and IP telephony (VoIP).
')
Task
In our case, it was necessary to provide secure access to a web resource using GOST encryption.
Requirements:
- Cluster configuration (solution requires high fault tolerance)
- High throughput
- Support for various browsers (IE, Mozilla, Chrome)
- The maximum number of connections in HTTPS proxy mode is 10,000
- Certificate of the Federal Security Service of Russia at SKZI
Decision
Below is a diagram and description of the components.
To solve this problem, the Security Code product “Continent TLS VPN” was selected, which meets all the above conditions.
It is worth noting that at the time of design it was the only certified PAC performing encryption according to GOST using the TLS protocol. In the future, it is expected to receive the ViPNet TLS PAK certificate from InfoTeX.
The main elements of the system:
- SKZI "Continent TLS VPN Client", version 1.2.1068
- Load Balancer, Netscaler v12
- SKZI "Continent TLS VPN Server", version 1.2.1.61
Item Description
SKZI "Continent TLS VPN Client" - a TLS client is a software installed on a computer of a remote user, which functions in conjunction with a TLS server. TLS-client is designed to implement secure access of remote users to the web resources of the corporate network through communication channels of common data networks.
NetScaler is an application delivery controller that provides flexible service delivery for traditional, container, and microservice applications from a data center or any cloud. Citrix Netscaler based balancer scatters HTTPS sessions between TLS server clusters. Answers from the WEB server also collects balancer.
SKZI "Continent TLS VPN Server" - the server is designed to provide secure access for remote users to protected resources.
Setup order
- We initialize the TLS server, configure the cluster, create certificate requests for the TLS server (CA root certificate, server certificate, certificate for remote server management, administrator certificate and CRL).
- Initial setup of TLS servers, import of certificates.
- Verify connectivity to a remote client protected resource using a TLS VPN Client.
Initialization
The first difficulty arose when running TLS-servers. The message “No controller found” has appeared. Together with the specialists of Security Code, a rather non-standard problem was identified. It turned out that the PAC refused to work in the data center with BenQ monitors, and worked with any others without problems.
The initial setup is simple and consists mainly of the definition of the ip-address and gateway, as well as the name of the device. Plus creation, export / import of a master key.
The customer in the project used two TLS servers. Both TLS servers must be active-active.
A master key is created on one server, and imported to other servers. The master key (cluster key) is designed for the following tasks:
- encryption of private keys of server certificates;
- organization of a secure connection between cluster members.
When exporting the master key, the TLS server received only a single USB flash drive from Transcend 3.0 4GB. No flash drives, even those that came bundled with the Security Code, unfortunately, did not fit.
Import Certificates
Next, you need to connect to the TLS server on the web face, define the protected resource and install certificates for server operation (CA root certificate, server certificate, certificate for remote server management, administrator certificate and CRL). All these certificates must be issued by one CA. For the first connection on the web-face, you need to use CryptoPro CSP, and not “CSP Security Code. In subsequent changes of certificates, it is better to first delete the root certificate of the CA, and then change other certificates.
Due to the inability to immediately make the combat certificates, it was decided to test the operation of the TLS server cluster on the certificates made on the Krypto Pro test center.
On TLS servers, it is possible to disable user authentication. In this case, a secure channel will be created if you have a TLS client and installed certificates (root, server certificate and CRL), i.e. personal certificate for work is not required.
Connection check
Initially, there were problems with connecting via a secure channel to a protected resource using the certified version of the TLS client from the Security Code. It turned out to connect to the protected resource using the TLS-client 2.0 from the Security Code, but this version is still at the certification stage. The problem was the wrong redirect on the protected resource, which did not pass, because the TLS servers did not quite correctly work out this rule in the release version of the firmware. To solve the problem, it was necessary to reflash both TLS servers and lift backups made.
The order of flashing is as follows:
- save the server base (so as not to create everything in a new way)
- upload image to flash using flashGUI
- We enter BIOS, previously in the settings of the Sobol PACK, we set the response time of the watchdog timer, which is sufficient to make changes to the BIOS settings.
- change the boot order, install the download from Flash, save
- At the start, there will be a message about changing sections, we agree
- during the installation process, select the debug version and the platform you use
- reboot, we enter BIOS, change the installation order, agree with the change
- we configure the server locally
- connect to server
- load the database
To enter debug mode on the TLS server, you must press the F2 key.
For version 1.2 file / usr / share / tls / webmgr / templates / websrv / nginx / base
Remove the proxy_redirect line from it and recalculate the checksums.
After the operations performed, a certified TLS-client from the "Security Code" earned, which the customer insisted on working in the system. But here’s the trick, it didn’t work in the Chrome browser, the work in which was just necessary for the customer, one could even say that everything was honed under it. A number of tests were conducted in conjunction with the support of the Security Code, and, as a result, everything worked on a slightly newer version (1.2.1073) than the certified version (1.2.1068).
By the way, one more of the pitfalls when setting up any TLS client from the Security Code (except for version 2.0) - they do not work on virtual machines. During testing, virtual machines were often used, which complicated the diagnostic process a little more.
findings
In the end I would like to summarize. The product is easy to configure and deploy. There is still something to work with developers, this applies to both the server and the client. But in general, the product is working and works in a cluster configuration. The system is currently running without failures and keeps the load. We hope that our stuffed bumps will help you deploy TLS Continent faster and more efficiently.
Article prepared by Ilya Platonov.
Source: https://habr.com/ru/post/353660/
All Articles