Ssl tls accept all certificates. Make sure ssl and tls are enabled

Network Protocols SSL and TLS are cryptographic protocols that provide authentication and protection against unauthorized access, violation of the integrity of transmitted data. The SSL/TLS protocols are designed to prevent client or server side identity spoofing, data disclosure or distortion. For these purposes, a reliable authentication method is used, communication channel encryption and message integrity codes are used. The default port for SSL/TLS is port 443 for HTTPS, 465 for SMTPS (email), 636 for LDAPS, 563 for NNTPS, 994 for IRCS (chat), 995 for POP3S.

SSL protocol

The SSL protocol was developed by Netscape to secure data between service and transport protocols. The first published version was released in 1995. Widely used for VoIP applications, instant messaging services. SSL is a secure channel that has the following properties:

Private channel. All messages are encrypted after the dialogue required to determine the encryption key.
The channel is authenticated. Authentication is optional for the client side, but mandatory for the server side.
Channel reliability. When messages are transported, an integrity check is performed using the MAC.

The SSL protocol uses both symmetric and asymmetric keys.

Features and purpose of the SSL protocol

The SSL protocol provides a solution to two problems - encryption of transmitted information and transfer of information exactly where it is required (authentication). The main purpose of the protocol is to provide a reliable way to exchange data between applications. The implementation of SSL is implemented as a multi-layer environment, which is used for the secure transmission of information through unsecured communication channels.

The layered structure is represented by a connection confirmation protocol layer and a recording protocol layer. The first layer is the transport protocol, for example, TCP - together with the SSL Record Protocol, these layers form the core of SSL, which subsequently participates in the formation of complex infrastructures.

Among the main features of the SSL protocol, software-platform independence should be noted. Currently, the SSL protocol does not provide adequate protection - it has been replaced by the TLS protocol.

TLS protocol

The TLS protocol is a cryptographic protocol that is used to securely transfer data between different nodes on the Internet. This protocol has found application in VoIP applications, web browsers, instant messaging applications. TLS is implemented on the SSL 3.0 specification. The IETF is involved in the development and development of the protocol.

The main security measures provided by the TLS protocol include:

The use of a key to verify a message's authentication code.
Eliminates the possibility of downgrading TLS or replacing it with a less secure network protocol.
The handshake message contains a hash of all messages exchanged between the parties.
Using application record numbering using MAC.
The use of a pseudo-random function that splits the input messages into 2 parts, each of which is processed by a different hash function.

Features and purpose of the TLS protocol

The TLS protocol uses the following algorithms:

RC4, Triple DES, SEED, IDEA, etc. for symmetric encryption.
RSA, DSA, Diffie-Hellman and ECDSA for key authentication.
MD5, SHA and SHA-256/384 for hash functions.

Applications exchange records that store data. Records can be compressed, padded, encrypted, or identified. In this case, each entry contains data on the length of the packet and the version of TLS used.

In general, the use of cryptography in SSL / TLS protocols significantly reduces application performance, but provides reliable protection data transmission. The protocols require almost no settings on the client side and are considered the most common security protocols on the Internet.

What is a TLS handshake and how it works

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

One of the key aspects of the protocol is the handshake. It is about him that we will talk in this article.

"SSL/TLS handshake" is the name of the HTTPS connection setup step. Most of the work related to the SSL/TLS protocol is done at this stage. Last year, the IETF finalized TLS 1.3 with a complete overhaul of the handshake process.
The article will cover two types of handshake - for the TLS 1.2 and TLS 1.3 protocols, which we will consider starting from the abstract level and gradually delving into the features:

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

How does the TLS handshake work?

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

Cipherset negotiation

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

That is why the first step of the TLS handshake is the exchange of information about its capabilities between the client and the server for further selection of 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. For a connection to be secure, 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 it depends on the ciphersuite used.

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

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

In this step, the client indirectly checks whether the server owns the private key associated with the certificate.

In RSA, the most common public key cryptosystem, the client uses the public key to encrypt random data that will be used to generate the 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 other party's authentication will still remain.

Key exchange

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

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

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

To complete the handshake, each party informs the other that it has completed all necessary work, and then verifies the checksums to make sure the handshake happened without any tampering or corruption.

The entire SSL handshake happens in a few hundred milliseconds. This is the first thing that happens on an HTTPS connection, even before the web page is loaded. 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 happened again. The TLS 1.3 handshake supports 0-RTT or zero round trip resume time, which greatly improves the speed for the returning visitor.

Handshake step by step 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 options so that the server can choose the ciphersuite it will use for communication. The message also includes a large randomly selected prime number, called the "customer random number".
The server politely responds with a "Server Hello" message. There it tells the client what connection options were chosen and returns its randomly chosen prime number, called the "server random number". If the client and server do not share cipher suites, then the connection fails.
In the "Certificate" message, the server sends its SSL certificate chain to the client, which includes leaf and intermediate certificates. After receiving them, the client performs several checks to verify the certificate. The client must also ensure that the server has private key certificate, which happens during the key exchange/generation process.
This is an optional message, only required 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 generating the session key. The specifics of this step depend on the key exchange method that was chosen in the original "Hello" messages. Since we're looking at RSA, the client will generate a random string of bytes called a pre-master secret, encrypt it with the server's public key, and send 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.
The message "Finished" is then sent, indicating that the handshake is completed on the client side. From that moment on, the connection is protected by the session key. The message contains data (MAC) that can be used to verify that the handshake has not been tampered with.
The server now decrypts the pre-master secret and calculates the session key. It 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 over 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.

Handshake step by step 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 triggers the handshake, but this time it contains much more information. TLS 1.3 has reduced the number of supported ciphers from 37 to 5. This means that the client can guess which key agreement or exchange protocol will be used, so it sends its part of the public key from the assumed protocol in addition to the message.
The server will respond with a "Server Hello" message. As in handshake 1.2, a certificate is sent at this point. 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 a "Server Finished" message.
Now that the client has all the information it needs, it verifies the SSL certificate and uses the two public keys to calculate its copy of the session key. When it's done, it sends a "Client Finished" message.

TLS handshake overhead

Historically, one of the complaints about SSL/TLS has been that it overloaded servers with additional overhead. This contributed to the now defunct notion that HTTPS is slower than HTTP.

Handshakes prior to 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 things down if there are a lot of them happening at the same time. Authentication, encryption and decryption are expensive processes.

On smaller websites this probably won't slow things down noticeably, but for corporate systems, where hundreds of thousands of visitors come every day, this can be a big problem. Each a new version handshakes make the process much easier: TLS 1.2 has 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 steps. In reality, many of these things happen at the same time, so 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 best 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 much faster than TLS 1.2.

Reducing cipher suites

No one was ever going to use 37 data encryption sets, that's how the protocol has evolved. Each time a new algorithm was added, new combinations were added, and soon IANA was administering 37 different cipher suites.

This is bad for two reasons:

This variability leads to misconfigurations that leave Internet users vulnerable to known exploits.
This made the SSL setup more confusing.

The IETF removed support for all but the most secure algorithms in TLS 1.3, removing confusion by restricting choice. In particular, the choice of the key exchange method has been removed. The ephemeral Diffie-Hellman scheme became the only way for a client to send its key information along with "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 retransmission time - 0-RTT

0-RTT is what the entire tech world has been aiming for, and here it is with TLS 1.3. As already 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 advantages of 0-RTT, it contains a couple of potential pitfalls. The mode makes clients susceptible to replay attacks, where an attacker who somehow manages to gain access to an encrypted session can obtain 0-RTT data, including the client's first request, and send it back to the server.

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

Safety

From the very beginning, the amount of information sent in clear text during the handshake was a concern. This is obviously insecure, so the more handshake steps that occur in encrypted form, the better.

In the TLS 1.2 handshake, the negotiation steps were not secure, instead a simple MAC function was used to prevent anyone from interfering 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 features (a downgrade attack). If both the server and the client support outdated cipher suites - this is easily obtained by listening to the connection - an attacker can change the encryption chosen by the server to a weaker one. Such attacks are not dangerous in and of themselves, but open the door to other known exploits of those cipher suites that the one originally chosen was changed to.

The TLS 1.3 handshake uses a digital signature in the early stages of a connection, making it more secure and protecting against ciphersuite-changing attacks. The signature also allows faster and more efficient server authentication.

Now let's see how these updates to the TLS 1.3 handshake will be implemented in all three major features 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 beginning 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 cipher suites

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 above example uses an ephemeral elliptic curve Diffie-Hellman (DH) system for key exchange and an elliptic curve digital signature algorithm for authentication. The DH can also be connected to 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 cipher suites

TLS is a protocol.
AES 256 GCM - Authenticated Encryption with Attached Data (AEAD).
SHA384 is a hashed key generation function (HKFD) algorithm.

We already know we'll be using some version of an ephemeral Diffie-Hellman 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 are still running, they just don't need to be negotiated during the 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 when creating version 1.3, security and performance improvements were the main focus. To do this, TLS 1.3 redesigned the key generation algorithm and fixed known vulnerabilities.

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

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

Authentication in TLS handshake

Historically the two main key exchanges are RSA and Diffie-Hellman (DH), these days DH is often associated with elliptic curves (ECDH). Despite some basic similarities, there are fundamental differences between the two key exchange approaches.

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

RSA uses simple factorization and modular arithmetic. Large prime numbers require a lot of CPU power to compute and are difficult to pick up.

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

A short digression into history may clarify this point.

As early as 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 secure key exchange over an insecure channel, even if an attacker is listening in on it. They succeeded, but there was one serious drawback: the DH key exchange did not include authentication, so it was not possible to verify the party on the other end of the connection.

This can be considered the birth of public key cryptography and PKI. Shortly after Diffie and Hellman introduced their key exchange protocol, the earliest versions of the RSA cryptosystem were completed. Diffie and Hellman have created the concept of public key encryption, but have not yet come up with the actual function of one-way encryption.

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 functional algorithm that can handle both key exchange and digital signatures, i.e., perform authentication in addition to secure key exchange. Therefore, RSA has larger keys: sufficient security must be provided for a 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 ciphersuites will pair with the Elliptic Curve Digital Signature Algorithm (ECDSA) or RSA.

TLS 1.2 handshake authentication

As just mentioned, the additional RSA functionality for digital signature authentication 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 the handshake.

On the other hand, if Diffie-Hellman doesn't authenticate, 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 they are based on. There are five suitable curves for this context:

192 bits;
224 bits;
256 bits;
384 bits;
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 the TLS handshake.

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

With Diffie-Hellman, the public/private key pair is NOT used for symmetric session key exchange. 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 linked to the key exchange process. More specifically, key exchange is part of the authentication process.

When a client is provided with a server's SSL certificate, it checks several metrics:

digital signature using a public key;
a certificate chain to make sure the certificate comes from one of the root certificates in the trust store;
expiration date to make sure it hasn't expired;
certificate revocation status.

If all these checks pass, then the last test is performed - the client encrypts the pre-master secret with 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 is granted access. This confirms 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 are deployed side by side. And that brings us back to the keys and their uses. The RSA public/private key is used for both key exchange and authentication. In DH + ECDSA/RSA, an asymmetric key pair is only used for the digital signature or authentication step.

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

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

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

TLS 1.3 handshake authentication

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

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

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

Instead of running a symmetric MAC to check the integrity of the handshake, the server signs the entire decryption hash when it returns "Server Hello" with its part of the public key.

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

A match confirms that the server owns the private 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 the shared secret and send it to the server, where it is used to calculate the corresponding session key. The DH key exchange doesn't really require a public key exchange at all, rather both parties create a key together.

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

RSA key exchange

Calling it an RSA key exchange is actually a misnomer. It's actually RSA encryption. RSA uses asymmetric encryption to generate the session key. Unlike DH, the public/private key pair plays a big role.

Here's how it goes:

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 with 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 even more PRFs and end up with matching session keys.

DH key exchange

Here is how ECDH works:

The client and server exchange two prime numbers ( x And y), which are called random numbers.
One side chooses a secret number called pre-master secret(a), and calculates: x a mod y. Then sends the result (A) to another 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 the given values and repeating the operation. One calculates b a mod y, the other computes a b mod y.

There is a modulo exponents property that says that each party 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've seen how DH differs from RSA, let's take a look at what a DH-based TLS 1.2 handshake looks like.

Again, there are many similarities between the 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 a client random number.
The server responds with its "Server Hello" message, which includes the selected ciphersuite 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 certificate authentication checks, but since the DH itself cannot authenticate the server, an additional mechanism is needed.
To authenticate, the server takes the random numbers of the client and server, 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 uses 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 option.
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 earlier to get the pre-master secret. Everyone then uses the pre-master secret they just calculated to get the same session key.
The client sends a "Change Cipher Spec" message to inform the other party that it has switched to encryption.
The client sends a final "Finished" message to indicate that it has completed its part of the handshake.
Similarly, 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 cryptographic community prefers to use DHE over RSA: perfect forward secrecy and known vulnerabilities.

Perfect Forward Secrecy

Earlier, you may have wondered what the word "ephemeral" means at the end of DHE and ECDHE. Ephemeral literally means "short-lived". And it can help to 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 being extracted and decrypted. PFS was given the highest priority after the discovery of the Heartbleed bug. This is the core component of TLS 1.3.

RSA key exchange vulnerability

There are vulnerabilities that could 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 fits into the larger public key, it must be padded. In most cases, if you try to guess the padding and send a fake request to the server, you will get it wrong, and it will recognize the mismatch and filter it out. But there is a good chance that you can send enough requests to the server to guess the correct padding. The server would then send an erroneous completed message, which would in turn narrow down 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 part of the shared key during the initial phase (Client Hello) of the handshake.

RSA was not the only key exchange scheme that was removed in TLS 1.3. Non-ephemeral Diffie-Hellman schemes have also been eliminated, as well as a list of insufficiently secure Diffie-Hellman parameters.

What is meant by insufficiently secure parameters? Without going 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 whole scheme will be useless. Diffie-Hellman schemes that could not provide large enough parameters were deprecated in TLS 1.3.

At the beginning of a TLS 1.3 handshake, knowing that a DHE key agreement scheme will be used, the client includes its part of the public 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 "Server Hello".
The client and server calculate the session key.

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

Instead of a conclusion

The SSL/TLS handshake is an exciting 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.

According to the requirements of Russian legislation, only the use of TLS connections established by Russian cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 and GOST R 34.10-2001. Therefore, if you need to use sites that use encryption according to GOST algorithms, you need to install the program " CryptoPro CSP» .

In operating rooms Windows systems the CryptoPro CSP program is used - a set of cryptographic utilities for generating electronic signature, work with certificates

To install CryptoPro CSP, use the materials from the official website:

After installing CryptoPro CSP Browser checks the existence and operation of this program.

Sites requesting GOST TLS encryption

If a site requests GOST TLS encryption, the browser checks if CryptoPro CSP is installed. If the program is installed, control is transferred to it.

Examples of sites requesting encryption: www.gosuslugi.ru , sites on the .gov.ru domain, .kamgov.ru , .nalog.ru .

If the site is not in the list, then additional confirmation is requested. If you trust the site and the connection must be made using GOST TLS encryption, click the Continue button.

All our reasoning is based on the fact that you are using Windows XP or later (Vista, 7 or 8), which have all the proper updates and patches installed. Now one more condition: we are talking about the latest versions of browsers today, and not “spherical Ognelis in a vacuum”.

So, we configure browsers to use the current versions of the TLS protocol and not use its outdated versions and SSL at all. In any case, as far as it is possible in theory.

And theory tells us that although Internet Explorer since version 8 it supports TLS 1.1 and 1.2, under Windows XP and Vista we will not force it to do so. Click: Tools / Internet Options / Advanced and in the "Security" section we find: SSL 2.0, SSL 3.0, TLS 1.0 ... found something else? Congratulations, you will have TLS 1.1/1.2! Not found - you have Windows XP or Vista, and in Redmond you are considered backward.

So, we remove the checkmarks from all SSLs, we put them on all available TLS. If only TLS 1.0 is available, then so be it, if there are more up-to-date versions, it is better to select only them, and uncheck TLS 1.0 (and not be surprised later that some sites do not open via HTTPS). Then click the "Apply", "OK" buttons.

With Opera, it’s easier - it arranges a real banquet for us from different versions protocols: Tools/General settings/Advanced/Security/Security protocols. What do we see? The whole set, from which we leave the checkboxes only for TLS 1.1 and TLS 1.2, after which we click the "Details" button and there we uncheck all the lines except those that start with "256 bit AES" - they are at the very end. At the beginning of the list there is a line "256 bit AES ( Anonymous DH/SHA-256), uncheck it too. Click "OK" and enjoy the security.

However, Opera has one strange property: if TLS 1.0 is enabled, then if it is necessary to establish a secure connection, it immediately uses this particular version of the protocol, regardless of whether the site supports more recent ones. Like, why strain - and everything is fine, everything is protected. When you enable only TLS 1.1 and 1.2, it will first try to use a more advanced version, and only if it is not supported by the site, the browser will switch to version 1.1.

But the spherical Ognelis Firefox will not please us at all: Tools / Settings / Advanced / Encryption: all we can do is turn off SSL, TLS is available only in version 1.0, there is nothing to do - we leave it with a tick.

However, the bad is learned in comparison: Chrome and Safari do not contain any settings at all, which encryption protocol to use. As far as we know, Safari does not support TLS versions more recent than 1.0 in versions under Windows, and since the release of new versions for this OS has been discontinued, it will not.

Chrome, as far as we know, supports TLS 1.1, but, as in the case of Safari, we cannot refuse to use SSL. Disabling TLS 1.0 in Chrome is also no way. But with the real use of TLS 1.1 - a big question: it was first turned on, then turned off due to problems in operation, and, as far as one can tell, it has not yet been turned back on. That is, support seems to be there, but it is, as it were, turned off, and there is no way to turn it back on to the user himself. The same story with Firefox - TLS 1.1 support in it, in fact, is, but it is not yet available to the user.

Summary from the above polyletter. What is the danger of using outdated versions of encryption protocols? The fact that someone else will get into your secure connection to the site and get access to all the information "there" and "there". In practical terms, it will full access to the box Email, an account in the client-bank system, etc.

It is unlikely that it will be possible to accidentally get into someone else's secure connection, we are only talking about malicious actions. If the probability of such actions is low, or the information transmitted over a secure connection is not of particular value, then you can not bother and use browsers that support only TLS 1.0.

Otherwise, there is no choice: only Opera and only TLS 1.2 (TLS 1.1 is just an improvement of TLS 1.0, partially inheriting its security problems). However, our favorite sites may not support TLS 1.2 :(

TLS is the 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 bit about technology

All enterprises and organizations that are engaged in financial transactions use this protocol to exclude wiretapping of packets and unauthorized access by intruders. This technology is designed to protect important connections from malicious attacks.

Basically, in their organization they use the built-in browser. In some cases - Mozilla Firefox.

Enable or disable a protocol

Some sites sometimes cannot be accessed due to the fact that support for SSL and TLS technologies is disabled. A notification pops up in the browser. So, how do you enable protocols to continue using 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 "Internet 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 changes. If you want to disable the protocols, which is highly discouraged, especially if you use Internet 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 related to Internet Explorer as a Windows component. If you do not have the TLS protocol checked in the settings, then there may be problems with Skype. The program simply will not be able to connect to the server.

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