Read about Internet traffic encryption tips


Encryption with SmartHide

Articles - Internet Traffic Encryption

Internet Traffic Encryption in big World

The technology of Internet-traffic protection from the unauthorized access is developing alongside with protected traffic interception technology. Non-encrypted user traffic interception and access to it is no longer a difficult task, even for an ordinary user. Practically everybody knows the word “sniffer”. In theory, it’s impossible to intercept secure  SSL/TSL connections. But is it really so?

Actually, not really. Yes, encrypted traffic is practically impossible to decrypt, but in reality, if one has a strong desire and the necessity, even the encrypted traffic can be decrypted once a key is found. But in order to do that, great resources are required. In this case the decryption makes sense only on the level of government or military interests.

When working over secure connections (the easiest example –  HTTPS) all the traffic between the interacting points in the Net is encrypted on the sender’s side and decrypted on the recipient’s side. Traffic is encrypted in both directions. In order to encrypt and decrypt the traffic you need a pair of keys (asymmetric cryptography). The public key is used for encryption and is sent to the data receiver, while the private key is used for decryption and is kept by the sender. In this way, hosts with SSL-connection between them exchange public keys. Further on, to improve the performance a single key is created, which is sent already encrypted and is used for both encryption and decryption on both ends (symmetric encryption).

And how do they do it? Usually, through the same channel which will be used to transfer the secure traffic after that. At the same time the key exchange takes place in an open mode. In case of HTTPS, the server key is connected with the certificate, which the user is suggested to look through and accept. And exactly this certificate can be intercepted by any intermediate server through which the certificate is transferred in an open mode (proxy, router).

In order to “read” all of the user’s traffic, the intermediate server substitutes this certificate by its own. That is it connects to the client with its certificate and at the same time connects to the remote server. The client receives a wrong certificate from the server-intruder and the browser informs the user about danger (such certificates never have signatures). The user has a choice: to accept the certificate and work with the site or reject it, but then it’s impossible to work with that site at all. Sometimes users ignore the content of certificates and automatically accept any data transferred by them.

If the user accepts the false certificate, the traffic will be transferred according to the following scheme:

Client<=SSL-connection=>server-wiretap<=SSL-connection=>destination server

That means that the intermediate server will receive all of your “secure” traffic in an open mode. It should be also noted that the certificate transmission takes place in the beginning of each HTTPS session.

In case of secured SSH, during the first connection with the server, the server key remains on the client side and the client’s key on the server. These keys are transmitted between the given client and the server only once, at the time of the first connection. If someone tries to intercept SSH-traffic in this case, both the client and the server will reject the connection because of keys mismatch. Since keys can be transferred between the client and the server through alternative ways (through a secure channel or on an external device), this connection method is relatively secure. It can only be blocked, making the user work openly.

It should be noted that the so-called “Enterprise information security solutions” which intercept the complete traffic transferred through an office proxy-server and “read” it have been sold for a long time already. The programs search for specific phrases or information of certain type in the data flow from browsers, e-mail programs, ftp-clients, office workers’ messengers. Besides, such programs can identify and process correctly different types of communication with servers. Particularly, they check secure SSL-traffic by certificates substitution. I had an almost first-hand experience in one of such systems development.

Anyhow, there are ways to escape such a total tracing. It is possible to direct any necessary traffic via installed SSH connection, which will be transferred from the SSH-server in an open mode to the destination recipient. This method is called SSH-tunneling. This way the traffic transfer through the unprotected channel can be secured, but this approach makes sense only when there is a trustworthy server with the set up and tunneling customized daemon. And it’s rather simple to organize it. The SSH-client connects to the server, configures to wiretap any specific port on the local computer. Such a client will provide SOCKS5-proxy service, i.e. its usage can be set up in any browser, e-mail program, IMs, etc. Packets get to the server through the SSH-tunnel and then transferred to the target server from it. The scheme is as follows:

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

Another way to protect traffic is a VPN-channel. It is easier and more convenient to use than SSH-tunneling, but it’s more complicated in the initial installation and setup. The main convenience is that you don’t have to write a proxy in programs. Some of the software doesn’t support proxy at all, consequently only VPN will be suitable.

However, if you are not familiar with the technical back-end of the methods above,  there is another easy-to-use and effective solution to encrypt your traffic. SmartHide is able to solve all the issues connected with Internet Traffic Encryption with a single click of a mouse button. Consider regestering SmartHide to secure your information and behavior in the Net for the future.

Copyright (c) SmartHide Security Octopus

Choose an internet traffic encryption article

Internet Traffic Encryption in big World

Practically everybody knows the word "sniffer". In theory, it's impossible to intercept secure SSL/TSL connections. But is it really so? >>>

Internet Traffic Encryption Basis

Practically everybody knows the word "sniffer". In theory, it's impossible to intercept secure SSL/TSL connections. But is it really so? >>>