Remote access using Continent TLS

According to statistics Positive Technologies found violations of information security regulations in 100% of companies in 2020. Among all violations, 64% of companies use insecure protocols. An unprotected protocol means that data is transmitted without encryption and has no protection from intruders.

And, if everything is clear with the protection of communication channels between branches (Site-to-Site VPN), then with remote access everything is not so simple. Many companies use remote access software, violating their own regulations, and in some cases, the law.

A number of regulatory documents in the field of information security require the use of secure remote access. One of the options for organizing secure remote access is the TLS protocol.

TLS (Transport Layer Security) – transport layer security protocol. The principle of its operation is as follows: an encrypted channel is established on top of TCP, through which data is transmitted via an application level protocol (HTTP, POP3, RDP, etc.)

TLS implements three components of data protection: authentication between the client and server, encryption and imitational protection (ensuring immutability) of data.

Encryption and imitation of data packets help protect transmitted information from intruders. Encryption uses symmetric algorithms, so after authentication, the client and server exchange symmetric keys.

A secure connection is established in several stages. This process is called a TLS handshake:

Data transmitted over the channel will be encrypted until the connection is terminated.

To establish a secure connection, modern cryptographic suites use the ephemeral Diffie-Hellman system. Diffie-Hellman can also be coupled to RSA. AES can be used for symmetric encryption. For hash functions, MD5, SHA-256/384 are used.

What should government agencies do that are required to use only domestic cryptography in their structures?

State bodies are required to use FSB-certified access means. With a massive transition to remote operation, the use of traditional VPN clients with support for GOST encryption becomes unprofitable, since they are licensed based on the total number of users.

In addition, a program is being developed to introduce domestic cryptography in the Russian segment of the Internet. The translation of government agencies' websites to TLS from GOST is necessary to fulfill Presidential Order No. Pr-1380 of July 16, 2016 “On ensuring the development and implementation of a set of measures necessary for the transition of government agencies to the use of Russian cryptographic algorithms and encryption tools.”

To solve these two problems, a relatively new class of devices is used – TLS-gateway with support for GOST encryption. Systems of this class combine TLS-offload mechanisms and mechanisms for restricting access to applications for remote users. The key feature of TLS-gateway is licensing not by the total, but by the simultaneous number of users.

TLS-offload – a mechanism for transferring encryption from the web server to a separate device. Due to this feature, the server can concentrate resources to perform basic functions.

TLS with Russian crypto suites was approved IANA organization, which manages the identifiers and protocol parameters of the Internet. Crypto kits use encryption algorithms GOST 28147-89, GOST R 34.12 (“Grasshopper” and “Magma”), which makes it possible to use the secure TLS data transfer protocol for government agencies.

To implement secure remote access to network resources, the Security Code company offers the Continent TLS solution.

The TLS continent is a complex consisting of a server and a client, designed for organizing remote access.

The complex implements the following cryptographic algorithms:

• GOST 29147-89 for information encryption;

• GOST R 34.11 for calculating the hash function;

• GOST R 34.10 for generating and verifying an electronic signature.

Continent TLS Certified to Requirements RD FSB of Russia and requirements RD FSTEC of Russia.

The complex consists of a TLS server and a TLS client. The Server redirects the Client's requests to the protected network, and the responses received from the protected network are redirected to the Client.

The following can act as a TLS client:

• Continent TLS client version 2;

• CryptoPro CSP versions 4.0, 5.0;

• Validata CSP version 5.0;

• Any other FSB-certified TLS client that supports TLS protocol versions 1.0 and 1.2

The TLS server provides three operating modes:

HTTPS proxy mode creates a secure HTTPS channel between clients and a TLS server using the TLS protocol.

TLS tunnel mode creates a secure tunnel for applications that use the TCP protocol.

In Application Portal mode, one entry point is used to access protected resources, access to which is restricted using the LDAP protocol. After authentication and authorization, the user will be offered a list of available protected resources from which he can select the one he needs. Otherwise, the operation of the TLS server in portal mode is similar to the HTTPS proxy mode.

Scenarios for using the Continent TLS system

Mass access to the government services portal

Initially, TLS Continent was created precisely for these purposes.

This happens as follows:

a) You must request a TLS client and server certificate from the server. Continent TLS client is a free program.

b) Set up a connection to the portal:

c) Install the server certificate:

If authentication is configured using a certificate, you will also need a client certificate:

d) When going to the portal, we receive a certificate selection prompt if certificate authentication is configured:

Or login using login and password:

The important thing here is the following:

• Data from the client to the server is transmitted via an encrypted communication channel in accordance with GOST;

• Continent TLS client allows you to receive configuration from the Server and, based on it, automatically configure available resources;

• The total number of users can be any. The licensing scheme is based on the total number of connected users (up to 45,000 simultaneously);

• Connecting to a resource is possible from several TLS clients;

• It is possible to configure both single-factor and two-factor authentication.

Remote access of employees to network resources

In addition to secure access to web applications, Continent TLS provides secure remote access to workstations. This connection is possible in TLS tunnel mode.

On the client side, the setup looks like this:
a) In the TLS client, configure a connection to the resource:

b) Create a request for a user certificate and submit it to the administrator of the certification authority:

c) Register the user and server certificates received from the administrator in the TLS client:

d) Connect to the remote desktop and select the user certificate:

Regulatory Compliance

The Continent TLS system is certified according to the requirements RD FSTEC for the 4th level of control lack of undocumented capabilities (NDV) of the software.

The presence of this FSTEC certificate allows you to use the complex for the following information systems:

• automated systems (AS) up to class 1G inclusive;

• state information systems (GIS) up to security class 1 inclusive;

• personal data information systems (ISPDn) up to class UZ1 inclusive.

The following have been implemented basic functions corresponding to the protection measures of FSTEC of Russia orders No. 17 and 21:

Access server + Continent-AP or Continent TLS

Continent-AP, in conjunction with an access server, provides remote access to network resources. Accordingly, the question arises: is there a difference between the Access Server and Continent-TLS?

The APKSH+SD combination is not suitable for implementing mass access to an electronic portal. Let's look at the differences when implementing access for remote employees.

Conclusion

Interest in organizing remote access has recently become increasingly relevant and Continent TLS is one of the options that not only provides secure remote access, but also meets the requirements of information security regulators.

Author of the article: Dmitry Lebedev, information security engineer