Checking tls connection. What is the TLS protocol? Configuring nginx to use client certificates

What is a TLS handshake and how does it work?

TLS is one of the most common security tools used on the Internet. The protocol actively works with many network communication processes: file transfers, VPN connections (in some implementations for key exchange), instant messaging services or IP telephony.

One of the key aspects of the protocol is the handshake. This is what we will talk about in this article.

"SSL/TLS handshake" is the name of the step in establishing an HTTPS connection. Most of the work associated with the SSL/TLS protocol is done at this stage. Last year, the IETF finalized TLS 1.3, completely revamping the handshake process.
The article will cover two types of handshakes - for the TLS 1.2 and TLS 1.3 protocols, which we will consider, starting from the abstract level and gradually delving into the specifics:

coordination of cryptographic protocols;
authentication using an SSL certificate;
session key generation.

How does a TLS handshake work?

An HTTPS connection involves two parties: the client (the initiator of the connection, usually a web browser) and the server. The purpose of the SSL/TLS handshake is to complete all cryptographic work to establish a secure connection, including verifying the authenticity of the SSL certificate used and generating an encryption key.

Dial negotiation

Each software unique. Therefore, even the most popular web browsers have different functionality. Likewise on the server side - Windows Server Apache and NGINX are also different from each other. Things get even more complicated when you add custom configurations.

This is why the first step of a TLS handshake is for the client and server to exchange information about their capabilities to further select supported cryptographic functions.

Once the client and server agree on the cipher suite to use, the server sends its SSL certificate to the client.

Authentication

Having received the certificate, the client checks its authenticity. This is an extremely important step. To ensure a secure connection, you not only need to encrypt the data, you also need to make sure that it is sent to the correct website. SSL/TLS certificates provide this authentication, and how they do this depends on the cipher suite used.

All trusted SSL certificates are issued by a certificate authority (CA). A CA must follow strict rules for issuing and validating certificates to be trusted. You can think of a CA as something like a notary public - its signature means that the data in the certificate is real.

During the authentication portion of the TLS handshake, the client performs several cryptographically secure checks to ensure that the server-issued certificate is valid. The process includes checking digital signature and whether the certificate was issued by a trusted CA.

At this point, the client indirectly checks whether the server owns the private key associated with the certificate.

In RSA, the most widely used cryptosystem with public key, the client uses a public key to encrypt random data that will be used to generate a session key. The server will be able to decrypt and use this data only if it has a private key, the presence of which ensures the authenticity of the party.

If a different cryptosystem is used, the algorithm may change, but the authenticity of the other party will still be verified.

Key exchange

The last part of the TLS handshake involves creating a "session key" that will actually be used for secure communication.

Session keys are "symmetrical", meaning the same key is used for encryption and decryption.

Symmetric encryption is faster than asymmetric encryption, making it more suitable for sending data over an HTTPS connection. The exact method of key generation depends on the cipher suite chosen, the two most common being RSA and Diffie-Hellman.

To complete the handshake, each party tells the other that it has done all the necessary work, and then checks the checksums to ensure that the handshake occurred without any interference or corruption.

The entire SSL handshake happens in a few hundred milliseconds. This is the first thing that will happen on an HTTPS connection, even before the web page loads. After the SSL handshake, an encrypted and authenticated HTTPS connection begins, and all data sent and received by the client and server is protected.

Up until TLS 1.3, every time you visited a site, the handshake would happen again. The TLS 1.3 handshake supports 0-RTT, or zero round-trip resume time, which greatly increases speed for the returning visitor.

Step-by-step handshake process in TLS 1.2

Let's take a closer look at the TLS handshake using RSA. The use of the Diffie-Hellman algorithm will be described below.

The first message is called "Client Hello". This message lists the client's capabilities so that the server can select the cipher suite to use for communication. The message also includes a large, randomly selected prime number called the “client random number.”
The server politely responds with a “Server Hello” message. There it tells the client what connection parameters have been selected and returns its randomly selected prime number, called the "server random number". If the client and server do not share the same cipher suites, the connection fails.
In the “Certificate” message, the server sends its SSL certificate chain to the client, including leaf and intermediate certificates. Once the client receives them, it performs several checks to verify the certificate. The client must also ensure that the server has private key certificate, what happens during the key exchange/generation process.
This is an optional message, required only for certain key exchange methods (such as Diffie-Hellman) that require additional data from the server.
The "Server Hello Done" message notifies the client that the server has finished transmitting data.
The client then participates in creating a session key. The specifics of this step depend on the key exchange method chosen in the original Hello messages. Since we're talking about RSA, the client will generate a random byte string called a pre-master secret, encrypt it with the server's public key, and pass it back.
The "Change Cipher Spec" message lets the other party know that the session key has been generated and can switch to an encrypted connection.
A "Finished" message is then sent, indicating that the handshake is complete on the client side. From this moment on, the connection is protected with a session key. The message contains data (MAC) that can be used to verify that the handshake has not been tampered with.
Now the server decrypts the pre-master secret and calculates the session key. Then sends a "Change Cipher Spec" message to notify that it is switching to an encrypted connection.
The server also sends a "Finished" message using the newly generated symmetric session key and verifies the checksum to verify the integrity of the entire handshake.

After these steps, the SSL handshake is complete. Both parties now have a session key and can communicate through an encrypted and authenticated connection.

At this point, the first bytes of the web application (data related to the actual service - HTML, Javascript, etc.) can be sent.

Step-by-step handshake process in TLS 1.3

The TLS 1.3 handshake is significantly shorter than its predecessor.

As with TLS 1.2, the "Client Hello" message initiates the handshake, but this time it contains much more information. TLS 1.3 reduced the number of supported ciphers from 37 to 5. This means that the client can guess what key agreement or exchange protocol will be used, so in addition to the message it sends its part of the public key from the guessed protocol.
The server will respond with a “Server Hello” message. As with the 1.2 handshake, a certificate is sent at this stage. If the client correctly guessed the encryption protocol with the attached data and the server agreed to it, the latter sends its part of the public key, calculates the session key and completes the transmission with the “Server Finished” message.
Now that the client has all the necessary information, it verifies the SSL certificate and uses the two public keys to calculate its copy of the session key. When this is done, it sends a "Client Finished" message.

Overhead of the TLS handshake

Historically, one of the complaints about SSL/TLS was that it overburdened servers with additional overhead. This influenced the now defunct notion that HTTPS is slower than HTTP.

Handshakes before TLS 1.2 required a lot of resources and, on a large scale, could seriously load the server. Even TLS 1.2 handshakes can slow down if there are many of them happening at one time. Authentication, encryption and decryption are expensive processes.

On smaller websites this probably won't cause any noticeable slowdown, but for corporate systems, where hundreds of thousands of visitors come every day, this can become a big problem. Each a new version handshakes significantly simplify the process: TLS 1.2 performs two phases, while TLS 1.3 fits into just one and supports 0-RTT.

TLS 1.3 handshake improvements over TLS 1.2

In the above explanation, the handshake is divided into ten separate stages. In reality, many of these things happen simultaneously, which is why they are often grouped together and called phases.

The TLS 1.2 handshake has two phases. Sometimes additional ones may be required, but when it comes to quantity, the default is the optimal scenario.

Unlike 1.2, the TLS 1.3 handshake fits into one phase, although it would be more accurate to say one and a half, but it is still significantly faster than TLS 1.2.

Reduction of cipher suites

No one ever intended to use 37 suites to encrypt data, which is how the protocol evolved. Every time it was added new algorithm, new combinations were added, and soon IANA administered 37 different cipher suites.

This is bad for two reasons:

This variability leads to erroneous configurations that leave Internet users vulnerable to known exploits.
This made setting up SSL more confusing.

The IETF removed support for all but the most secure algorithms in TLS 1.3, eliminating confusion by limiting choice. In particular, the choice of key exchange method has been removed. The ephemeral Diffie-Hellman scheme became the only way, allowing the client to send its key information along with the "Client Hello" in the first part of the handshake. RSA encryption has been completely removed along with all other static key exchange schemes.

That being said, there is one potential Achilles' heel in TLS 1.3.

Zero round trip resume time - 0-RTT

0-RTT is what the entire tech world has been clamoring for, and now it's here with TLS 1.3. As mentioned, the TLS handshake has historically been slow, so it was important to speed it up. 0-RTT does this by storing some secret information about the client, usually a session ID or session tickets, for use on the next connection.

Despite all the benefits of 0-RTT, it does contain a couple of potential pitfalls. The mode makes clients susceptible to replay attacks, where an attacker who somehow manages to gain access to the encrypted session can obtain the 0-RTT data, including the client's first request, and send it back to the server.

However, the exploit is not easy to use. This risk is probably a small price to pay for an extremely useful feature.

Safety

From the beginning, there was concern about the amount of information sent in clear text during a handshake. Obviously this is not secure, so the more handshake steps that happen encrypted, the better.

In the TLS 1.2 handshake, the negotiation stages were not protected, instead using a simple MAC function to ensure that no one interfered with the transmission. The negotiation phase includes "Client Hello" and "Server Hello" messages.

The MAC function acts as an indicator, but does not provide any security guarantees. You may have heard of an attack that forces parties to use less secure protocols and functions (downgrade attack). If both the server and the client support outdated cipher suites - information about this can be easily obtained by eavesdropping on the connection - an attacker can change the encryption chosen by the server to a weaker one. Such attacks are not dangerous in themselves, but open the door to the use of other known exploits of the cipher suites that the original one was changed to.

The TLS 1.3 handshake uses a digital signature early in the connection, making it more secure and protecting against cipher-breaking attacks. The signature also allows you to authenticate the server faster and more efficiently.

Now let's see how these updates to the TLS 1.3 handshake will be implemented in all three major functions of the SSL/TLS handshake itself.

TLS handshake cipher suites

A cipher suite is a set of algorithms that determine the parameters of a secure connection.

At the start of any connection, the very first interaction, "Client Hello", is a list of supported cipher suites. The server chooses the best, most secure option that it supports and meets its requirements. You can look at the cipher suite and figure out all the handshake and connection parameters.

TLS 1.2 ciphersuites

TLS is a protocol.
ECDHE is a key exchange algorithm.
ECDSA is an authentication algorithm.
AES 128 GCM is a symmetric encryption algorithm.
SHA256 is a hashing algorithm.

The example above uses the ephemeral Elliptic Curve Diffie-Hellman (DH) system for key exchange and the Elliptic Curve digital signature algorithm for authentication. DH can also be coupled with RSA (functioning as a digital signature algorithm) to perform authentication.

Here is a list of the most widely supported TLS 1.2 cipher suites:

TLS 1.3 ciphersuites

TLS is a protocol.
AES 256 GCM is an authenticated encryption algorithm with attached data (AEAD).
SHA384 is the hash key generation function algorithm (HKFD).

We already know that we will use some version of Diffie-Hellman ephemeral key exchange, but we don't know the parameters, so the first two algorithms in the TLS 1.2 cipher suite are no longer needed. These functions still work, they just don't need to be negotiated during a handshake anymore.

From the above example, you can see that AES (Advanced Encryption Standard) is used to encrypt a large amount of data. It operates in Galois counter mode using 256-bit keys.

Here are the five cipher suites that are supported in TLS 1.3:

TLS_AES_256_GCM_SHA384;
TLS_CHACHA20_POLY1305_SHA256;
TLS_AES_128_GCM_SHA256;
TLS_AES_128_CCM_8_SHA256;
TLS_AES_128_CCM_SHA256.

What has changed in TLS 1.3 compared to TLS 1.2?

It's important to remember that version 1.3 was designed with security and performance improvements in mind. To achieve this, in TLS 1.3 the key generation algorithm was redesigned and known vulnerabilities were fixed.

The TLS 1.3 handshake also improves some processes, such as message authentication and digital signatures.

Finally, in addition to phasing out older key generation or exchange algorithms, TLS 1.3 eliminates older symmetric ciphers. TLS 1.3 completely eliminated block ciphers. The only type of symmetric cipher allowed in TLS 1.3 is called Authenticated Encryption with Additional Data (AEAD). It combines encryption and message authentication (MAC) into one function.

Authentication in TLS handshake

Historically, the two main key exchange options are RSA and Diffie-Hellman (DH), these days DH is often associated with Elliptic Curve Key Exchange (ECDH). Despite some basic similarities, there are fundamental differences between these two approaches to key exchange.

In other words, the RSA TLS handshake is different from the ECDH TLS handshake.

RSA uses prime factorization and modular arithmetic. Large prime numbers require a lot of CPU power to calculate and are difficult to find.

Diffie-Hellman is sometimes called exponential key exchange, which indicates exponentiation (in addition to modular arithmetic), but DH itself doesn't actually encrypt or decrypt anything at all. So calling it "encryption method" instead of "mathematical reasoning" may be a little misleading.

A short excursion into history can clarify this point.

Back in 1976, Whitfield Diffie and Martin Hellman created a key exchange protocol based on the work of Ralph Merkle, whose name, according to both, should also appear in the name of the protocol.

They tried to solve the problem of securely exchanging keys over an insecure channel, even if an attacker is listening to it. They succeeded, but there was one major flaw: the DH key exchange did not include authentication, so there was no way to verify the party on the other end of the connection.

This can be considered the birth of public key cryptography and PKI. Soon after Diffie and Hellman introduced their key exchange protocol, the most early versions RSA cryptosystems. Diffie and Hellman had created the concept of public key encryption, but had not yet come up with the one-way encryption feature itself.

It was Ron Rivest (R in RSA) who created the concept that eventually became the RSA cryptosystem.

In many ways, RSA is the spiritual successor to DH. It carries out:

key generation;
key exchange;
encryption;
decryption.

Thus, RSA is a more capable algorithm that can handle both key exchange and digital signatures, that is, authentication in addition to secure key exchange. Therefore, RSA has larger keys: sufficient security must be provided for the digital signature.

While RSA handles authentication and key exchange, Diffie-Hellman only facilitates key exchange. There are four common variants of the DH family:

Diffie-Hellman (DH);
ephemeral (short-term) Diffie-Hellman (DHE);
elliptic curve Diffie-Hellman (ECDH);
Elliptic Curve Ephemeral Diffie-Hellman (ECDHE).

Again, Diffie-Hellman by itself does not authenticate anything. It must be used in conjunction with a digital signature algorithm. So, for example, if you used ECDH or ECDHE, most cipher suites will be paired with Elliptic Curve Digital Signature Algorithm (ECDSA) or RSA.

Authentication in TLS 1.2 handshake

As just mentioned, the additional functionality of RSA for authentication using digital signatures requires large keys that are resistant to brute-force attacks. The size of these keys greatly increases the cost of computing, encrypting, and decrypting them during a handshake.

On the other hand, if Diffie-Hellman doesn't perform authentication, then what does it do? As mentioned above, DH is often used in conjunction with elliptic curve cryptography to provide authentication and key exchange.

Elliptic cryptography (ECC) has much smaller key sizes that fit the elliptic curve on which it is based. There are five suitable curves for this context:

192 bits;
224 bits;
256 bit;
384 bit;
521 bits.

But that's not the only difference between ECC public/private keys and RSA keys. They are used for two completely different purposes during a TLS handshake.

In RSA, the public/private key pair is used for both server authentication and symmetric session key exchange. In fact, it is the successful use of the pre-master secret that authenticates the server.

With Diffie-Hellman, the public/private key pair is NOT used to exchange a symmetric session key. When Diffie-Hellman is involved, the private key is actually associated with the accompanying signature algorithm (ECDSA or RSA).

RSA authentication

The RSA authentication process is related to the key exchange process. More precisely, key exchange is part of the authentication process.

When a client is presented with a server's SSL certificate, it checks several indicators:

digital signature using a public key;
a certificate chain to ensure that the certificate comes from one of the root certificates in the trust store;
expiration date to ensure it has not expired;
certificate revocation status.

If all these checks have passed, then the last test is carried out - the client encrypts the pre-master secret using the server's public key and sends it. Any server can try to pass off any SSL/TLS certificate as its own. After all, these are public certificates. And so the client can authenticate the server by seeing the private key “in action”.

Thus, if the server can decrypt the pre-master secret and use it to calculate the session key, it gains access. This verifies that the server is the owner of the public/private key pair being used.

DH authentication

When Diffie-Hellman and ECDSA/RSA are used, authentication and key exchange work side by side. And that brings us back to keys and their uses. RSA public/private key is used for both key exchange and authentication. In DH+ECDSA/RSA, the asymmetric key pair is used only for the digital signature or authentication phase.

When the client receives the certificate, it still performs the standard checks:

verifies the signature on the certificate,
chain of certificates,
validity,
review status.

But ownership of a private key is verified differently. During the TLS handshake key exchange (step 4), the server uses its private key to encrypt the client and server random number, as well as its DH parameter. It acts as a digital signature for the server, and the client can use the associated public key to verify that the server is the rightful owner of the key pair.

Authentication in TLS 1.3 handshake

In TLS 1.3, authentication and digital signatures still play an important role, but they have been removed from cipher suites to simplify negotiation. They are implemented on the server side and use several algorithms supported by the server due to their security and ubiquity. TLS 1.3 allows three main signature algorithms:

RSA (signature only),
Elliptic Curve Digital Signature Algorithm (ECDSA),
Edwards Digital Signature Algorithm (EdDSA).

Unlike the TLS 1.2 handshake, the authentication portion of the TLS 1.3 handshake is not associated with the key exchange itself. Rather, it is processed in parallel with key exchange and message authentication.

Instead of running a symmetric MAC circuit to verify the integrity of the handshake, the server signs the entire decryption hash when it returns a “Server Hello” with its portion of the shared key.

The client receives all the information passed from the "Server Hello" and performs a standard series of SSL/TLS certificate authentication checks. It involves checking the signature on the certificate and then checking against the signature that was added to the decryption hash.

A match confirms that the server owns the secret key.

Key exchange in TLS handshake

If you highlight the main idea of this section, it will sound like this:

RSA facilitates key exchange by allowing the client to encrypt a shared secret and send it to the server, where it is used to calculate the corresponding session key. DH key exchange doesn't actually require a public key exchange at all, rather both parties create a key together.

If this sounds a little abstract now, it should all become clearer by the end of this section.

RSA Key Exchange

Calling it RSA key exchange is actually a misnomer. This is actually RSA encryption. RSA uses asymmetric encryption to create the session key. Unlike DH, the public/private key pair plays a big role.

Here's how it happens:

x And y
Client generates pre-master secret(a) and then uses the server's public key to encrypt it and send it to the server.
Server decrypts pre-master secret using the corresponding private key. Now both sides have all three input variables and mix them with some pseudo random functions (PRF) to create a master key.
Both parties mix the master key with another big amount PRF and obtain matching session keys.

DH Key Exchange

Here's how ECDH works:

The client and server exchange two prime numbers ( x And y), which are called random numbers.
One party chooses a secret number called pre-master secret(a), and calculates: x a mod y. Then sends the result (A) to the other participant.
The other side does the same, choosing their own pre-master secret(b) and calculates x b mod y, and then sends back its value (B).
Both sides end this part by accepting set values and repeating the operation. One calculates b a mod y, the other calculates a b mod y.

There is a modulo property that says that each side will receive the same value, which will be the key used for symmetric encryption during the connection.

TLS 1.2 handshake for DH

Now that we know how DH differs from RSA, let's look at what a DH-based TLS 1.2 handshake looks like.

Again, there are many similarities between these two approaches. We will use ECDHE for key exchange and ECDSA for authentication.

As with RSA, the client starts with a "Client Hello" message, which includes a list of ciphersuites as well as the client's random number.
The server responds with its “Server Hello” message, which includes the selected cipher suite and the server’s random number.
The server sends its SSL certificate. As with the RSA TLS handshake, the client will perform a series of checks on the authenticity of the certificate, but since DH itself cannot authenticate the server, an additional mechanism is needed.
To perform authentication, the server takes the client and server random numbers, as well as the DH parameter that will be used to calculate the session key, and encrypts them with its private key. The result will act as a digital signature: the client will use the public key to verify the signature and that the server is the rightful owner of the key pair, and will respond with its own DH parameter.
The server ends this phase with a "Server Hello Done" message.
Unlike RSA, the client does not need to send the pre-master secret to the server using asymmetric encryption; instead, the client and server use the DH parameters they exchanged previously to obtain the pre-master secret. Everyone then uses the pre-master secret they just calculated to obtain the same session key.
The client sends a "Change Cipher Spec" message to inform the other party that it is switching to encryption.
The client sends a final "Finished" message to indicate that it has completed its portion of the handshake.
Likewise, the server sends a “Change Cipher Spec” message.
The handshake ends with a “Finished” message from the server.

Advantages of DHE over RSA

There are two main reasons why the cryptographer community prefers to use DHE over RSA: perfect forward secrecy and known vulnerabilities.

Perfect forward secrecy

Previously, you may have wondered what the word “ephemeral” at the end of DHE and ECDHE means. Ephemeral literally means “short-lived.” And this can help understand Perfect Forward Secrecy (PFS), which is a feature of some key exchange protocols. PFS ensures that session keys exchanged between parties cannot be compromised, even if the certificate's private key is compromised. In other words, it protects previous sessions from extraction and decryption. PFS received highest priority after discovering the Heartbleed bug. This is a core component of TLS 1.3.

RSA Key Exchange Vulnerability

There are vulnerabilities that can exploit padding ( padding), used during key exchange in older versions of RSA (PKCS #1 1.5). This is one aspect of encryption. With RSA, the pre-master secret must be encrypted with the public key and decrypted with the private key. But when this smaller pre-master secret is placed in a larger public key, it must be padded. In most cases, if you try to guess the content and send a fake request to the server, you will be wrong, and it will recognize the discrepancy and filter it out. But there is a good chance that you will be able to send enough requests to the server to guess the correct filling. Then the server will send an erroneous completed message, which in turn will narrow the possible value of the pre-master secret. This will allow an attacker to calculate and compromise the key.

This is why RSA was removed in favor of DHE in TLS 1.3.

Key exchange in TLS 1.3 handshake

In a TLS 1.3 handshake, due to the limited choice of key exchange schemes, a client can successfully guess the scheme and send its portion of the shared key during the initial (Client Hello) phase of the handshake.

RSA wasn't the only key exchange scheme that was removed in TLS 1.3. Non-ephemeral Diffie-Hellman schemes were also eliminated, as was the list of insufficiently secure Diffie-Hellman parameters.

What do you mean by insufficiently secure settings? Without getting into the math, the complexity of Diffie-Hellman and most public key cryptosystems is the complexity of solving discrete logarithm problems. The cryptosystem must be complex enough to compute if the input parameters (client and server random numbers) are unknown, otherwise the entire scheme will be useless. Diffie-Hellman schemes, which could not provide large enough parameters, were eliminated in TLS 1.3.

At the beginning of a TLS 1.3 handshake, knowing that the DHE key agreement scheme will be used, the client includes its portion of the shared key based on the intended key exchange scheme in its "Client Hello" message.
The server receives this information and, if the client is correct, returns its part of the public key in a "Server Hello".
The client and server calculate the session key.

This is very similar to what happens with DH in a TLS 1.2 handshake, except that in TLS 1.3 the key exchange happens earlier.

Instead of a conclusion

The SSL/TLS handshake is a fun process that is key to safe internet, and yet it happens so quickly and quietly that most people never even think about it.

At least until something goes wrong.

TLS is a successor to SSL, a protocol that provides secure and secure connection between nodes on the Internet. It is used in the development of various clients, including browsers and client-server applications. What is TLS in Internet Explorer?

A little about technology

All enterprises and organizations that engage in financial transactions use this protocol to prevent eavesdropping of packets and unauthorized access by intruders. This technology is designed to protect important connections from attacks by intruders.

Basically, their organizations use a built-in browser. In some cases - Mozilla Firefox.

Enabling or disabling a protocol

It is sometimes impossible to access some sites because support for SSL and TLS technologies is disabled. A notification appears in the browser. So, how can you enable protocols so you can continue to enjoy secure communications?
1.Open Control Panel via Start. Another way: open Explorer and click on the gear icon in the upper right corner.

2.Go to the “Browser Options” section and open the “Advanced” block.

3.Check the boxes next to “Use TLS 1.1 and TLS 1.2.”

4.Click OK to save your changes. If you want to disable the protocols, which is highly not recommended, especially if you use online banking, uncheck the same items.

What is the difference between 1.0 and 1.1 and 1.2? 1.1 is only a slightly improved version of TLS 1.0, which partially inherited its shortcomings. 1.2 is the most secure version of the protocol. On the other hand, not all sites can open with this protocol version enabled.

As you know, the Skype messenger is directly connected to Internet Explorer as Windows component. If you do not have a check mark TLS protocol in the settings, then problems may arise with Skype. The program simply will not be able to connect to the server.

If TLS support is disabled in Internet Explorer settings, all network-related functions of the program will not work. Moreover, the safety of your data depends on this technology. Do not neglect it if you perform financial transactions in this browser (purchases in online stores, transferring money through online banking or e-wallet, etc.).

If you are encountering an issue where access to a specific site is failing and a message appears in your browser, there is a reasonable explanation for this. The causes and solutions to the problem are given in this article.

SSL TLS protocol

Users of budgetary organizations, and not only budgetary ones, whose activities are directly related to finance, in interaction with financial organizations, for example, the Ministry of Finance, the Treasury, etc., conduct all their operations exclusively using the secure SSL protocol. Basically, in their work they use the Internet Explorer browser. In some cases - Mozilla Firefox.

SSL Error

The main attention when carrying out these operations, and work in general, is paid to the security system: certificates, electronic signatures. CryptoPro software is used for work current version. Concerning problems with SSL and TLS protocols, If SSL error appeared, most likely there is no support for this protocol.

TLS error

TLS error in many cases it can also indicate a lack of protocol support. But... let's see what can be done in this case.

SSL and TLS protocol support

So, when using Microsoft Internet Explorer to visit an SSL-secured website displays in the title bar Make sure ssl and tls protocols are enabled. First of all, you need to enable support for the TLS 1.0 protocol in Internet Explorer.

If you are visiting a website that runs Internet Information Services 4.0 or higher, configuring Internet Explorer to support TLS 1.0 helps secure your connection. Of course, provided that the remote web server you are trying to use supports this protocol.

To do this in the menu Service select team Internet Options.

On the tab Additionally In chapter Safety, make sure the following checkboxes are selected:

Use SSL 2.0
Use SSL 3.0
Use SSL 1.0

Click the button Apply , and then OK . Restart your browser .

After enabling TLS 1.0, try visiting the website again.

System Security Policy

If they still occur errors with SSL and TLS If you still can't use SSL, the remote web server probably doesn't support TLS 1.0. In this case, you must disable the system policy that requires FIPS-compliant algorithms.

To do this, in Control panels select Administration, and then double-click Local Security Policy.

In Local Security Settings, expand Local policies and then click the button Security Settings.

According to the policy on the right side of the window, double click System cryptography: use FIPS-compliant algorithms for encryption, hashing and signing and then click the button Disabled.

Attention!

The change takes effect when the local security policy is reapplied. Turn it on and restart your browser.

CryptoPro TLS SSL

Update CryptoPro

One of the options to solve the problem is to update CryptoPro, as well as configure the resource. In this case, this is working with electronic payments. Go to Certification Authority. Select Electronic Marketplaces as the resource.

After launch automatic settings workplace, there will only be wait for the procedure to complete, then reload browser. If you need to enter or select a resource address, select the one you need. You may also need to restart your computer when setup is complete.