This is the third chapter on the choice of VPN, we have previously considered the choice of the number of VPN servers. Based on your tasks and expectations, you have had to decide whether you need a Single VPN or a chain of VPN servers. We have also reviewed the protocols; I assume that most of you have stopped at the OpenVPN protocol, this is a reasonable choice.
We are talking exclusively about the server part, since in the future you will have to choose a program on your device with the help of which you will use a VPN.
But even before the transition to the choice of the program we need to consider a number of parameters: TLS authentication, connection port, session key, encryption algorithm, key length and data authentication.
Although many people are familiar with the number of servers and the choice of protocol, still these indicators are often frightening for non-specialists. But nothing will be difficult, as I will try to tell you as clearly as possible about each of them.
TLS authentication
Do you remember in the chapter on encryption I talked about Caesar's cipher? Suppose the Senate receives a messenger from Caesar, but how can senators verify that this ambassador is really from the emperor? Maybe his cipher was intercepted by malefactors who sent their message encrypted with the key of Caesar?
Imagine that the messenger knows some kind of unique password, only by naming which one he will be accepted at his destination. This is how TLS authentication works. The handshake package (the process of starting the interaction between the user and the VPN server) is signed by a special key that the server knows. If the package is not signed or the signature is not correct, such a package is ignored.
Many services claim TLS authentication as their advantage, as it sounds solid, although in fact it is rather an important necessity. They just throw dust in the eyes of customers.
Connection port
Coming back to Caesar, here he gave the encrypted text to the messenger, who must deliver it to the Senate. The messenger has many ways how to reach the Senate. There are the most popular trodden roads, but if the enemy wants to interrupt the message, they can block these roads. Even if the messenger will not be intercepted, the enemy scouts will notice for sure that Caesar sends messengers to the Senate.
But there are almost unknown paths where the enemy will never wait for the messenger, and if you send a messenger to one of them, he will not be detected or intercepted. There are also important roads, along which the main trade exchange goes and it is simply impossible to block them without causing significant harm to oneself.
There is exactly the same situation with the ports. VPN has standard ports that depend on the protocol used:
- OpenVPN 1194
- PPTP 1723
- IPsec 500 and 4500
As a rule, VPN providers use standard ports. This allows sites to detect the presence of a VPN and Internet service providers and system administrators to block its use.
Not all VPN protocols can change ports, however, in the case of OpenVPN it is possible. If your Internet provider or system administrator blocks VPNs, we recommend using OpenVPN over TCP on port 443. TCP traffic on port 443 is the most important way, it cannot be blocked, because this port is used for HTTPS. The port used for VPN can be seen in the configuration file, which we will work with in one of the following parts.
As you know from the previous chapter, TCP is not the best choice in terms of speed, but there is a way out. OpenVPN can be configured in such a way that at first it will try to use the connection via UDP and in case of problems after a specified period of time it will connect via TCP.
Session key generation
Simple users find it difficult to understand the key generation process, so I will try to tell about it using the example of Caesar and the Senate. Caesar used his key shifting one letter from day to day from year to year. After some time he realized that in this way he could not communicate with each senator separately, since every key holder can read the sent message and in general it is not very safe.
What was Caesar’s decision?
- The key must be unique for each senator.
- The key must be changed after each correspondence.
To do this one needs to come up with some kind of technology for creating a remote key, as Caesar is on the battlefield, while senators are in Rome. One could simply send it to the desired senator by the messenger, but then the enemies would be able to intercept it and figure out how the encryption key is created. So Caesar figured out how to solve this problem.
Initially, both the senator and Caesar know the common key (namely shifting letters one character to the right), which is Caesar's standard cipher. This key is not known to the enemy. Next, Caesar sends the message “+ 2 left” to the senator with the messenger, which means that the cipher text will be shifted two characters alphabetically to the left in addition to the original right shift by one character. The senator notes this and in response he sends Caesar: "We change the letters" O "in each odd line: O to A in the source text", thus they will create a unique key not known to other senators by sending messengers to each other.
Even if the enemy intercepts the data, they will not receive the final key, because they do not know the original key that Caesar and the senator had before the exchange of these messages. After all, they began to shift the letters already having taken into account the initial displacement. The more messengers they send in the key creation process and the more complicated the initial encryption method is, the harder it will be for the enemy to get the key for decrypting the correspondence.
Similarly, in the encryption of data from the client to the VPN server a session key generation mechanism is used. To do this, temporary keys are exchanged using the Diffie-Hellman algorithm and a certificate is used to confirm the fact of the exchange with the VPN server. As a rule, it is 1024-, 2048- and 4096-bit.
Many VPN providers use 2048 or even 1024 for several reasons.
- The smaller this indicator is, the less is the load on the VPN server and the user's processor. Generating a key is not such an easy job.
- The smaller this indicator is, the slower the battery consumption of the mobile device will be. Everything is clear: the load on the processor is the trouble for the battery.
- The complexity of generating slows down the process of connecting to a VPN. You probably noticed that from the moment you click the "Connect" button before connecting to the server it takes some time, it will increase or decrease depending on the bit depth.
- Many people think that 2048 bits is enough and 4096 is over too much security.
Using a 2048 bit metric is the right move from a business point of view. 99% of users still do not understand the significance of this indicator, at the same time it will reduce the load on the server when generating the session key and speed up the process of connecting the user to the VPN, which will certainly be a plus for the service.
RSA 512, a formerly standard of reliability, was hacked in 1999. Scientists from Michigan were able to “hack” the 1024-bit long key using simple computers in 2010, it took them 100 hours, but back to 2003 Israeli scientists were able to hack it using a supercomputer. Therefore, we strongly recommend not to use VPN with RSA 1024 bits.
RSA is the most popular key encryption algorithm, but not the only one. You can experience, for example, a VPN based on elliptic curves. In my opinion, RSA is time-tested and reliability comparison is a question for mathematicians, but not for security experts. Elliptic curves have some advantages in terms of speed and load on devices, but they are not as significant as sellers of similar VPNs claim.
Let's go back to the key length. Sometimes they write that the 2048-bit key is also unreliable and can be hacked. In fact, any key can be, but for a long-length key really large powers are needed, which, according to our information,are not available nowadays neither for malefactors, nor for special services. However, this is not the ultimate truth. In 2010 scientists learned how to “hack” RSA 1024, so RSA 2048 could become the next. Most likely, they have already learned how to do it and we just don’t know about it.
In the next chapter we will talk about the encryption algorithm, key length and data authentication.