Security (encryption) traffic

In parallel with the development of technologies for protecting Internet traffic from unauthorized access, technologies for intercepting secure traffic are also developing. Intercepting and studying unencrypted user traffic has long been difficult, even for an ordinary user. Almost everyone knows the word "sniffer". Theoretically, secured SSL / TSL connections cannot be intercepted by conventional means. But is it?

In fact - not quite. Yes, it is theoretically impossible to decrypt the encrypted traffic, although again, theoretically, with a very large need and desire, such traffic can be decrypted by selecting the key. However, this requires such a cost of resources that the relevance of hacking persists only, probably, at the government or military level :)

When working over a secure connection (the simplest example is HTTPS ), all traffic between interacting points in the network is encrypted on the sender's side and decrypted on the recipient's side. Encrypted traffic going in both directions. In order to encrypt and decrypt it, you need a pair of keys (asymmetric encryption). The public key is used for encryption and is transmitted to the recipient of data, and the private key is used for decryption, it remains with the sender. Thus, the nodes between which an SSL connection is established exchange public keys. Further, to improve performance, a single key is generated, which is already sent in encrypted form and is used both for encryption and for decryption on both sides (symmetric encryption).

And how do they do it? Usually - on the same channel through which the protected traffic will continue. Moreover, the key exchange takes place in open mode. In the case of HTTPS, the server key is associated with a certificate that the user is invited to view and accept. And this certificate can intercept any intermediate server, in the path of which the certificate goes in open form (proxy, router).
')
To further “read” all user traffic, the intermediate server replaces the certificate with its own. Those. he simply connects to the client with his certificate, and at the same time connects to the remote server. The client receives a “left” certificate from the attacker server, and the browser informs the user about the danger (such certificates are not always signed). The user has a choice: to accept the certificate and work with the site, or refuse to accept it, but then it will not work with the site. Sometimes users ignore the contents of certificates altogether and automatically accept any transferred to them.

If the user accepts a fake certificate, then the traffic will go as follows:

client <= SSL connection => server listening <= SSL connection => destination server

Those. the intermediate server will receive all your "protected" traffic in the clear. It is also worth noting that the transfer of the certificate occurs at the beginning of each HTTPS session.

In the case of secure SSH, the server key is stored on the client during the first connection with the server, and the client key is stored on the server. These keys are transferred between data to the client-server only once, during the first connection. If in this case the SSH traffic is attempted to be intercepted, then both the client and the server will fail to connect due to a mismatch of keys. Since the keys can be transferred between the client and the server in a detour (via a secure channel or on external media), this connection method is relatively safe. It can only be blocked, forcing the user to work in the open.

It is worth noting that so-called “enterprise information security solutions” have long been on sale, which intercept all traffic passing through an office proxy server and “read” it. Programs look for the presence of certain phrases or information of a certain type in the data stream from browsers, mail programs, ftp-clients, messengers of the office staff. Moreover, these programs are able to distinguish and handle correctly the most different types of information interaction with servers. In particular, they check SSL-protected traffic by replacing certificates. I came across almost directly the development of one of these systems.

But there are ways to save from total surveillance. Through the established SSH connection, you can send any desired traffic, which from the SSH server will already go in open form to the end point. This method is called SSH tunneling. This way you can secure the traffic through an unprotected channel, but this approach makes sense only if you have a trusted server with an SSH daemon raised and tuned in to the tunneling. And to organize it is quite simple. The SSH client connects to the server and is configured to listen on any given port on the local machine. This client will provide the SOCKS5 proxy service, i.e. its use can be configured in any browser, email programs, IM, etc. Through the SSH tunnel, the packets go to the server, and from it go to the target server. The scheme is obtained as follows:

[localhost: client <=> proxy] <== SSH connection ==> server <=> target server

Another way to protect traffic is the VPN channel. In use, it is simpler and more convenient than SSH-tunneling, but in the initial installation and configuration more difficult. The main convenience of this method is that the programs do not need to register a proxy. And some software does not support the proxy at all, therefore only the VPN will do.

In practice, there are two options for work. The first is the purchase of a VPN account, which is sold specifically for this purpose (encrypting traffic over an insecure channel). In this case, accounts are usually sold, you need to connect to them using PPTP (normal VPN, which is implemented, for example, in Windows) or L2TP.

The second option is to buy a VDS server (virtual dedicated server) with any Linux distribution kit on board and bring up a VPN server on it. VDS can be Russian or American (just do not forget about overseas pings), cheap (from $ 5) and weak or expensive and more powerful. An OpenVPN server is installed on a VDS, and an OpenVPN client is raised on a computer. For Windows, there is even a GUI version of the client .

If you decide to use the variant with OpenVPN, that is, for example, this simple step-by-step instruction on raising the server (Debian). Installing the client is even easier, especially under Windows. Mark is only one point. If all traffic needs to be sent over the created VPN connection, then you need to set the default gateway to the VPN gateway (the redirect-gateway parameter in the client’s config), and if only part of the traffic (to certain hosts), you can register the usual static routes to these hosts ( by IP; for example, route add -p 81.25.32.25 10.7.0.1).

For the connection OpenVPN key exchange occurs in manual mode, i.e. it is absolutely safe to transport them from the server to the client.

Thus, SSH and VPN connections can almost completely guarantee the security of your traffic when moving through an unsecured channel. The only problem that may arise in this case is the prohibition of SSL traffic on the corporate firewall. If SSL traffic is allowed at least on any one port (usually the default 443), then you can potentially raise both the SSH tunnel and the VPN connection by setting up the appropriate daemon on your VDS on this port.